Page History

...

For MM2 users who use a custom ReplicationPolicy they will not be able to use replication.policy.separator to control internal topics suffix, these users will need to handle these methods if they wish to customise it or use the `replication.policy.separator`

...

2- Add a configuration for the full name of each topic however this would add more fields to MirrorMaker 2 config and , this looks simple from the first look however this solution have many downsides

1. Increasing MirrorMaker2 config as the more advanced and complicated is replication design between

...

1. clusters the more config will be needed if the clusters don't share the same naming convention for topics.

...

1. For example use cases where user migrating data from multiple clusters used by different teams who don't share the same naming conventions.
2. MM2 needs to distinguish between internal topics from different clusters, for example right now the name for offset-syncs topic to mm2-offset-syncs.<cluster-alias>.internal and for checkpoints is <cluster-alias>.checkpoints.internal so the name has a pattern to link it back to the herder of source -> target mirror. So for keeping backward compatibility we will need the MM2 config to load cluster aliases first in order to determine the default value of these 2 topics.

3. Allowing users to set full name for each topic may create more problem if the user by mistake used the same topic for multiple clusters. For example, considering use case where MM2 is used to mirror between multiple clusters

   Code Block
   title MM2 config
   source1 -> target.enabled = true source2 -> target.enabled = true

   Now if user set the same topic for checkpoints for both source1 and source2 this will led MM2 to push checkpoints data for both source clusters into one topic which goes against one of MM2 designs decisions regards distinguishing internal topics from each cluster.