Page History

...

If users delete a topic configuration in the source cluster, currently it would also be deleted from the target cluster due to the replace all behaviour of AlterConfigs API. However with IncrementalAlterConfigs, the topic configuration in the target cluster would potentially be left unchanged. Therefore any the default topic configuration on the source cluster would need to be deleted from will explicitly be cleared from  the target cluster via Delete operation when using IncrementalAlterConfigs API. 

The KIP also proposes adding the ability for users to choose between target cluster's default or source cluster's default when using IncrementalAlterConfigs for syncing topic configurations. For instance, users would be able to configure ConfigPropertyFilter to check if the configuration on the source topic is the default and choose whether or not to replicate it the default configurations of the source topic to the target topiccluster. This gives users a bit more control in how they want to replicate their topic configurations. 

...

2) Extend ConfigPropertyFilter  class to have a new method called shouldReplicateSourceDefault which would return false by default. If set to false while using IncrementalAlterConfigs API, the default configurations in the source cluster will explicitly be cleared from the target cluster using the Delete operation. User would be able to configure this method to return true in order to replicate include source cluster's default configurations in the replication.  

3) Extend DefaultConfigPropertyFilter with default valuesa new property "use.defaults.from" that accepts "source" and "target" values. This will allow users to control which cluster's defaults get applied on the target. The user can also use the existing "config.properties.exclude" property to exclude configuration from the replication regardless of which cluster's default is chosen. 

34) From Kafka 4.0, MirrorMaker will use IncrementalAlterConfigs API for syncing topic configuration. 

...