# mm2.properties source.cluster.bootstrap.servers=10.0.1.7:9092 target.cluster.bootstrap.servers=10.2.1.7:9092 producer.compression.type=lz4
异地机房的数据比生产机房晚 40 分钟，MM2 的 replication lag 显示 1.2GB，源集群出带宽只有 200Mbps，专线峰值已经跑满。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，复制任务按 topic 分区并行拉取，单分区吞吐受专线带宽和 RTT 限制。MM2 默认的 producer 批次和压缩没有针对高延迟链路调整。
「Kafka 跨机房复制」确认了原因之后，改动尽量只碰那一处，顺手改的东西后面最容易出问题。改完隔一天再看一次，当场正常不代表能稳住。
测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。
日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。
处理上按这个顺序：把复制链路的 compression.type 改成 lz4 降低字节数；调大 producer batch.size 和 linger.ms 让每次 RTT 多带数据；按 topic 拆分 MM2 任务 核心 topic 单独走一条链路；监控 replication lag 而不是只看消费 lag。
改完只确认一件事：专线占用降到 70% 以下 复制延迟稳定在 5 分钟以内。