主主复制允许断连的最长时长是多少？是否有相关配置？

核心结论 #

主主复制通常可以承受1小时的断连，无需立刻更换方案，但最终可行性取决于数据库事务量、binlog配置和磁盘容量，同时需要做好关键配置优化与监控。

关键影响因素 #

• Binlog日志容量：断连期间主库会将待同步事务写入binlog，只要1小时内产生的binlog未超出磁盘预留空间，且binlog保留策略（如expire_logs_days或binlog_expire_logs_seconds）不会在重连前清理未同步日志，就不会出现数据丢失风险。
• 事务冲突概率：若两个校区业务是隔离写入（如A校区仅操作A分区数据，B校区仅操作B分区），断连期间几乎不会产生冲突；若存在跨校区写同一份数据的场景，需提前通过业务规则规避（如全局唯一ID、分区键约束），否则重连时会触发复制冲突。
• 重连同步效率：断连积压的事务需在网络恢复后同步，只要带宽足够，通常几分钟即可完成；带宽不足时会出现短暂延迟，但不会导致复制中断（只要binlog未丢失）。

必要配置优化 #

• 调整binlog保留时长：将binlog_expire_logs_seconds设置为远大于1小时的值（如7200秒以上），避免断连期间binlog被自动清理。
• 可选开启半同步复制：若对数据一致性要求极高，可开启主主半同步，确保至少一个节点确认事务后再返回客户端，但需注意断连时会触发写入阻塞，需结合业务场景权衡。
• 监控binlog状态：实时监控主库binlog占用空间和未同步日志量，设置告警阈值，当binlog接近磁盘容量或未同步量超标时及时处理。

需更换方案的场景 #

仅在以下情况发生时，才考虑切换到其他方案（如异步复制+定期全量备份、分布式数据库或异地多活架构）：

• 1小时断连产生的binlog量持续超出磁盘可用空间，且无法扩容磁盘；
• 跨校区写冲突频繁，业务层面无法有效规避；
• 重连后同步延迟持续过长，严重影响业务可用性。

内容的提问来源于stack exchange，提问作者Andrew Williams