Skip to content

Conversation

@ryannedolan
Copy link
Contributor

@ryannedolan ryannedolan commented May 7, 2021

Enable active/passive, one-way replication without renaming topics, similar to MM1. This implementation is described in KIP-382 (adopted), originally as "LegacyReplicationPolicy".

This enables operators to migrate from MM1 to MM2 without re-architecting their replication flows, and enables some additional use-cases for MM2. For example, operators may wish to "upgrade" their Kafka clusters by mirroring everything to a completely new cluster. Such a migration would have been difficult with either MM1 or MM2 previously.

When using IdentityReplicationPolicy, operators should be aware that MM2 will not be able to detect cycles among replicated topics. A misconfigured topology may result in replicating the same records back-and-forth or in an infinite loop. However, we don't prevent this behavior, as some use-cases involve filtering records (via SMTs) to prevent cycles.

This PR includes major contributions from @mdedetrich and @ivanyu, so please include them in the commit log!

@ryannedolan ryannedolan changed the title WIP KAFKA-9726 LegacyReplicationPolicy (Ryanne's version) KAFKA-9726 IdentityReplicationPolicy May 21, 2021
@ryannedolan ryannedolan marked this pull request as ready for review May 21, 2021 21:05
@mdedetrich
Copy link
Contributor

@ryannedolan Since #10762 was merged maybe it makes sense to rebase against the current trunk? Some of the tests in this PR have assert statements without the failure messages which have been just been fixed (I believe you can just copy some of those assert failure messages to make sure its consistent).

@mdedetrich
Copy link
Contributor

@mimaison As my PR at #10648 has been superseded by this one, would it be possible to do a quick review of it? Afaik its ready and @ryannedolan has done great work in avoiding the need for a KIP so there shouldn't be any blockers.

@ryannedolan
Copy link
Contributor Author

None of the failing tests are related. Ready to merge.

@mimaison
Copy link
Member

mimaison commented Jun 7, 2021

@ryannedolan @mdedetrich Thanks, I'll try to take a look this week

Copy link
Member

@mimaison mimaison left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @ryannedolan for the PR. It looks good overall, I left a few small comments

@ryannedolan
Copy link
Contributor Author

@mimaison thanks for the feedback and suggestions. I've updated accordingly.

@ryannedolan ryannedolan requested a review from mimaison June 21, 2021 21:21
@mdedetrich
Copy link
Contributor

@ryannedolan I actually just realized, does it make sense to add the IdentityReplicationPolicy to the release notes so that people are aware of it (talking about docs/streams/upgrade-guide.html)

@mimaison
Copy link
Member

Yes, we can add a line in https://github.com/apache/kafka/blob/trunk/docs/upgrade.html#L85 to introduce this new ReplicationPolicy

@mdedetrich
Copy link
Contributor

mdedetrich commented Jun 28, 2021

Is there anything left on this PR to be merged (apart from the changelog which is a nice to have)?

@ryannedolan
Copy link
Contributor Author

I think changelog and documentation updates can come after this is merged.

@mimaison
Copy link
Member

Let's put a line in the changelog now so we're sure it's included in the release notes. I'm happy to merge once this is done.

I agree the documentation can come later.

in <code>new ConsumerGroupMetadata(consumerGroupId)</code> to work with older brokers. See <a href="https://cwiki.apache.org/confluence/x/zJONCg">KIP-732</a> for more details.
</li>

<li> The Connect-based MirrorMaker (MM2) includes changes to support <code>IdentityReplicationPolicy</code>, enabling replication without renaming topics.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would make a quick amendment stating that it works like the original MM1 to make it more clear.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I think it's enough, thanks

@mimaison
Copy link
Member

@ryannedolan I was about to merge but I noticed IdentityReplicationIntegrationTest.testOffsetSyncsTopicsOnTarget() is failing. It probably needs some adjustements to work with this policy as the computed offset-syncs topic name looks odd:

org.opentest4j.AssertionFailedError: Condition not met within timeout 30000. Unable to find checkpoints for primarytest-topic-1 ==> expected: <true> but was: <false>

@ryannedolan
Copy link
Contributor Author

testOffsetSyncsTopicsOnTarget

Yep good catch. Fixed!

@mimaison mimaison merged commit 93f5737 into apache:trunk Jul 1, 2021
@mimaison
Copy link
Member

mimaison commented Jul 1, 2021

Thanks @ryannedolan, @mdedetrich and @ivanyu

mdedetrich added a commit to aiven/kafka that referenced this pull request Jul 1, 2021
This new policy enables active/passive, one-way replication without renaming topics, similar to MM1. This implementation is described in KIP-382 (adopted), originally as "LegacyReplicationPolicy".

This enables operators to migrate from MM1 to MM2 without re-architecting their replication flows, and enables some additional use-cases for MM2. For example, operators may wish to "upgrade" their Kafka clusters by mirroring everything to a completely new cluster. Such a migration would have been difficult with either MM1 or MM2 previously.

When using IdentityReplicationPolicy, operators should be aware that MM2 will not be able to detect cycles among replicated topics. A misconfigured topology may result in replicating the same records back-and-forth or in an infinite loop. However, we don't prevent this behavior, as some use-cases involve filtering records (via SMTs) to prevent cycles.

Reviewers: Mickael Maison <mickael.maison@gmail.com>

Co-authored-by: Ryanne Dolan <rdolan@twitter.com>
Co-authored-by: Matthew de Detrich <mdedetrich@gmail.com>
Co-authored-by: Ivan Yurchenko <ivanyu@aiven.io>
ivanyu added a commit to aiven/kafka that referenced this pull request Jul 2, 2021
KAFKA-9726: Add IdentityReplicationPolicy to MirrorMaker2 (apache#10652)
ivanyu added a commit to aiven/kafka that referenced this pull request Jul 9, 2021
This new policy enables active/passive, one-way replication without renaming topics, similar to MM1. This implementation is described in KIP-382 (adopted), originally as "LegacyReplicationPolicy".

This enables operators to migrate from MM1 to MM2 without re-architecting their replication flows, and enables some additional use-cases for MM2. For example, operators may wish to "upgrade" their Kafka clusters by mirroring everything to a completely new cluster. Such a migration would have been difficult with either MM1 or MM2 previously.

When using IdentityReplicationPolicy, operators should be aware that MM2 will not be able to detect cycles among replicated topics. A misconfigured topology may result in replicating the same records back-and-forth or in an infinite loop. However, we don't prevent this behavior, as some use-cases involve filtering records (via SMTs) to prevent cycles.

Reviewers: Mickael Maison <mickael.maison@gmail.com>

Co-authored-by: Ryanne Dolan <rdolan@twitter.com>
Co-authored-by: Matthew de Detrich <mdedetrich@gmail.com>
Co-authored-by: Ivan Yurchenko <ivanyu@aiven.io>
props.putAll(stringsWithPrefix("header.converter"));
props.putAll(stringsWithPrefix("task"));
props.putAll(stringsWithPrefix("worker"));
props.putAll(stringsWithPrefix("replication.policy"));

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In MirrorClientConfig ,it seems that it's not necessary to add replication.policy into the props.
As i see , org.apache.kafka.connect.mirror.MirrorClientConfig#replicationPolicy initialise the ReplicationPolicy instance,
and in MirrorClient this instance is used ,where ReplicationPolicy takes effect for real.


<li> The Connect-based MirrorMaker (MM2) includes changes to support <code>IdentityReplicationPolicy</code>, enabling replication without renaming topics.
The existing <code>DefaultReplicationPolicy</code> is still used by default, but identity replication can be enabled via the
<code>replication.policy</code> configuration property. This is especially useful for users migrating from the older MirrorMaker (MM1), or for

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think it's more clear to say "replication.policy.class " here ,you know , which means it's configured in that form in mm2.properties file.

Friendly to beginners .

ivanyu added a commit to aiven/kafka that referenced this pull request Sep 23, 2021
This new policy enables active/passive, one-way replication without renaming topics, similar to MM1. This implementation is described in KIP-382 (adopted), originally as "LegacyReplicationPolicy".

This enables operators to migrate from MM1 to MM2 without re-architecting their replication flows, and enables some additional use-cases for MM2. For example, operators may wish to "upgrade" their Kafka clusters by mirroring everything to a completely new cluster. Such a migration would have been difficult with either MM1 or MM2 previously.

When using IdentityReplicationPolicy, operators should be aware that MM2 will not be able to detect cycles among replicated topics. A misconfigured topology may result in replicating the same records back-and-forth or in an infinite loop. However, we don't prevent this behavior, as some use-cases involve filtering records (via SMTs) to prevent cycles.

Reviewers: Mickael Maison <mickael.maison@gmail.com>

Co-authored-by: Ryanne Dolan <rdolan@twitter.com>
Co-authored-by: Matthew de Detrich <mdedetrich@gmail.com>
Co-authored-by: Ivan Yurchenko <ivanyu@aiven.io>
juha-aiven pushed a commit to aiven/kafka that referenced this pull request Dec 9, 2021
This new policy enables active/passive, one-way replication without renaming topics, similar to MM1. This implementation is described in KIP-382 (adopted), originally as "LegacyReplicationPolicy".

This enables operators to migrate from MM1 to MM2 without re-architecting their replication flows, and enables some additional use-cases for MM2. For example, operators may wish to "upgrade" their Kafka clusters by mirroring everything to a completely new cluster. Such a migration would have been difficult with either MM1 or MM2 previously.

When using IdentityReplicationPolicy, operators should be aware that MM2 will not be able to detect cycles among replicated topics. A misconfigured topology may result in replicating the same records back-and-forth or in an infinite loop. However, we don't prevent this behavior, as some use-cases involve filtering records (via SMTs) to prevent cycles.

Reviewers: Mickael Maison <mickael.maison@gmail.com>

Co-authored-by: Ryanne Dolan <rdolan@twitter.com>
Co-authored-by: Matthew de Detrich <mdedetrich@gmail.com>
Co-authored-by: Ivan Yurchenko <ivanyu@aiven.io>
xdgrulez pushed a commit to xdgrulez/kafka that referenced this pull request Dec 22, 2021
This new policy enables active/passive, one-way replication without renaming topics, similar to MM1. This implementation is described in KIP-382 (adopted), originally as "LegacyReplicationPolicy".

This enables operators to migrate from MM1 to MM2 without re-architecting their replication flows, and enables some additional use-cases for MM2. For example, operators may wish to "upgrade" their Kafka clusters by mirroring everything to a completely new cluster. Such a migration would have been difficult with either MM1 or MM2 previously.

When using IdentityReplicationPolicy, operators should be aware that MM2 will not be able to detect cycles among replicated topics. A misconfigured topology may result in replicating the same records back-and-forth or in an infinite loop. However, we don't prevent this behavior, as some use-cases involve filtering records (via SMTs) to prevent cycles.

Reviewers: Mickael Maison <mickael.maison@gmail.com>

Co-authored-by: Ryanne Dolan <rdolan@twitter.com>
Co-authored-by: Matthew de Detrich <mdedetrich@gmail.com>
Co-authored-by: Ivan Yurchenko <ivanyu@aiven.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants