What does sync.topic.configs.enabled do, and which topic configurations does MM2 keep in sync on the target?
answer
- sync.topic.configs.enabled — default true
- Copies cleanup.policy / retention / segment / min.insync, etc.
- config.property.filter.class excludes throttle props
- interval default 600s
- replication.factor is SEPARATE, set at topic creation
basics
~10 sWhen sync.topic.configs.enabled=true (the default), MM2 periodically copies the source topic's configuration (like cleanup.policy, retention, etc.) onto the mirrored target topic so they stay consistent. A property filter controls which config keys are synced.
solid answer
~40 s`sync.topic.configs.enabled` (default true) makes MirrorSourceConnector periodically read each source topic's dynamic config and apply it to the corresponding remote topic on the target, so things like `cleanup.policy`, `retention.ms`, `min.insync.replicas`, `segment.bytes`, and compaction settings don't drift. The set of keys synced is governed by `config.property.filter.class` (DefaultConfigPropertyFilter), which by default syncs most properties but excludes a few that shouldn't be copied (e.g. `follower.replication.throttled.replicas`, `leader.replication.throttled.replicas`). Sync cadence is `sync.topic.configs.interval.seconds` (default 600s). Importantly, `replication.factor` is NOT a copied topic config — it's a separate MM2 setting that fixes the RF of topics MM2 creates on the target, because source and target clusters often have different broker counts.
go deeper
Know it keeps target topic settings (like retention) matching the source, and it's on by default.
Name several synced configs, the sync interval, and that a property filter governs which keys are copied.
Distinguish config sync from replication.factor, explain the throttle-property exclusion, and discuss overwriting manually pre-created target topics.
Define a config-sync policy across clusters with different durability/broker-count profiles, deciding which keys to exclude and how RF/partition expansion propagate.
## The problem A mirrored topic on the target is a **separate** topic object from its source — it has its own broker placement, partition leaders, and **topic-level configuration**. Without synchronization, an operator changing `retention.ms` on the source would leave the target topic with stale settings, causing divergent retention/compaction behavior. `sync.topic.configs.enabled` solves this. ## What it does When `true` (the default), MirrorSourceConnector runs a periodic job — every `sync.topic.configs.interval.seconds` (default 600s) — that reads the **dynamic** topic configs of each replicated source topic via an AdminClient `describeConfigs`, then issues `incrementalAlterConfigs`/`alterConfigs` on the matching target topic to make them match. Synced settings typically include: - `cleanup.policy` (delete vs compact), - `retention.ms`/`retention.bytes`, - `segment.bytes`, - `max.message.bytes`, - `min.insync.replicas`, - `compression.type`, and so on. This keeps consumer-visible behavior (how long data lives, whether it compacts) consistent across clusters. ## The property filter Not every config should be copied verbatim. `config.property.filter.class` (default `DefaultConfigPropertyFilter`) decides which keys are eligible. The default excludes a handful — notably the replication-throttle properties (`leader.replication.throttled.replicas`, `follower.replication.throttled.replicas`) — because those reference broker/replica identities that are meaningless on the other cluster. You can also use the `use.defaults.from` setting to choose whether topic defaults are pulled from the source or target. Override the filter class for custom policy (e.g., never sync `min.insync.replicas` if the target has different durability requirements). ## replication.factor — a common confusion RF is **not** part of `sync.topic.configs`. When MM2 auto-creates a topic on the target, it does so with the `replication.factor` setting (default 2; older versions 3) — a flat MM2 property, optionally overridden per topic via `<topic>.replication.factor`. This is deliberate: the source might be a 5-broker cluster with RF=3 while the target DR cluster has only 2 brokers, so blindly copying RF would make target topic creation fail. Likewise `replication.policy` controls remote naming (out of scope here). So: - **data and config sync** are continuous; - **RF** is fixed at target-topic creation time by a dedicated setting. ## Edge cases - (1) If you disable config sync, manual config drift is your responsibility. - (2) Number of **partitions** is also kept in sync — if the source topic is expanded, MM2 adds partitions on the target on the next refresh (it can add but not remove partitions, matching Kafka's own constraint). - (3) Config sync only applies to topics MM2 manages; if you pre-create a target topic manually with different settings, the next sync cycle will overwrite the eligible keys to match the source unless you exclude them via the filter.
- Is replication.factor copied as part of sync.topic.configs? Why or why not?No. RF is a distinct MM2 setting (default 2) applied when MM2 creates the target topic. Source and target clusters often differ in broker count, so copying the source RF could make target topic creation fail or be unsafe.
- Which kinds of topic configs does the default property filter deliberately NOT sync?The replication-throttle properties (leader.replication.throttled.replicas / follower.replication.throttled.replicas), because they reference broker/replica IDs specific to the source cluster and are meaningless on the target.
saying these in an interview costs you the question
- Claiming sync.topic.configs copies replication.factor — it does not; RF is a separate setting at creation time.
- Saying every topic config key is synced — the property filter excludes throttle properties by default.
- Thinking config sync is one-time at creation — it runs periodically (default every 600s).
- Assuming MM2 can shrink partition count to match — it can only add partitions, like Kafka itself.