Page History

...

• When set to "requested", MirrorMaker will use the IncrementalAlterConfigs for syncing topic configurations. If it the first request receives an error from an incompatible broker,it will use fallback to the deprecated AlterConfigs API instead for the subsequent calls and log a WARN message e.g. "The target cluster <ALIAS> is not compatible with IncrementalAlterConfigs API. Therefore using deprecated AlterConfigs API for syncing topic configurations."". Users would then need to restart or reconfigure to go back to using IncrementalAlterConfigs API. 

• When explicitly set to "never", MirrorMaker will use the deprecated AlterConfigs API for syncing topic configurations.
• When explicitly set to "required", MirrorMaker will use the IncrementalAlterConfigs API for syncing topic configurations. If it receives an error from an incompatible broker, the MirrorMaker will report this to the user and fail the connector.

...

By default, the new setting will be set to "required"  which means we'll use IncrementalAlterConfigs if possible, and fallback to AlterConfigs API if incompatible. 

This means there will be a behaviour change while syncing topic configurations in MM2 after this KIP. For example, if changing retentions.ms of a topic in the source cluster, filtered configurations such as follower.replication.throttled.replicas of the topic currently get cleared in the target cluster. After this KIP, the current value of follower.replication.throttled.replicas would be kept in the target cluster unless the target broker's version is older than Kafka 2.3.0. 

...