MySQL 5.7 复制中断主因是 expire_logs_days 过短导致 binlog 被过早清理，而非 max_binlog_size 过小；二者须协同调整，并优先保障从库最大延迟期间的 binlog 可用性。
MySQL 5.7 默认的 max_binlog_size 是 1GB，但实际中频繁滚动 binlog（比如每几分钟就切一个 mysql-bin.0000xx）本身不会直接导致复制中断；真正引发问题的是：主库过早清理旧 binlog，而从库还没来得及拉取，造成 IO 线程报错 Could not find first log file name in binary log index file 或 Client requested master to start replication from position > file size。
为什么增大 max_binlog_size 不能根治复制中断
单纯调大 max_binlog_size 只是让单个 binlog 文件存更久、切得更少，但它不解决根本矛盾：
- binlog 还是会被
expire_logs_days清理——这才是从库“断档”的主因 - 如果写入压力高（例如批量导入、大事务集中提交），即使设成 2GB，也可能几分钟就写满，照样高频切换
- 从库延迟高时，哪怕只多切一次 binlog，就可能跨过它还没读的位置，触发
Relay_Log_Pos找不到对应事件
max_binlog_size 和 expire_logs_days 必须协同调整
光改一个参数是无效的。你得按从库最大可能延迟反推保留时间：
- 先用
SHOW SLAVE STATUS\G观察Seconds_Behind_Master峰值，比如最高到 1800 秒（30 分钟） - 再查主库当前 binlog 总量增长速率：
du -sh /var/lib/mysql/mysql-bin.* | tail -n 20，估算 1 小时写多少 GB - 若 1 小时写 0.8GB，那 30 分钟约 0.4GB → 单个 binlog 设为
max_binlog_size = 512M更稳妥（避免切太碎） - 同时把
expire_logs_days = 3（至少覆盖 3 天延迟缓冲）
GTID 模式下更要警惕 max_binlog_size 的副作用
在 GTID 模式（gtid_mode=ON）下，max_binlog_size 过小会导致：
- 每个 binlog 文件包含的事务数变少，GTID 集合（
Executed_Gtid_Set）碎片化更严重 - 从库执行
CHANGE MASTER TO MASTER_AUTO_POSITION=1时，主库需扫描更多 binlog 文件定位起始位点，IO 压力上升 - 极端情况下，频繁切 binlog + 主库高并发，可能触发
ER_BINLOG_LOGGING_IMPOSSIBLE错误（日志写入竞争）
比调参更关键的实操动作
与其花时间反复试 max_binlog_size，不如立刻做这几件事：
- 确认所有从库都开启了
relay_log_recovery=ON，防止崩溃后 relay log 不一致 - 在主库上运行
SELECT @@global.expire_logs_days, @@global.max_binlog_size;，检查是否被动态修改过（有些运维脚本会悄悄重置） - 用
mysqlbinlog --base64-output=decode-rows -v mysql-bin.000123 | head -30看单个文件里事务密度，判断是否真由切得太勤引起中断 - 如果错误日志明确出现
Could not open log file或log file not found，90% 是expire_logs_days设置过短，不是max_binlog_size的锅
真正容易被忽略的点：MySQL 5.7 的 max_binlog_size 是软限制——当一个大事务（如 INSERT ... SELECT）跨越文件边界时，整个事务会强制写进下一个文件，导致实际文件大小远超设定值。所以看监控不能只盯“文件数量”，得结合 SHOW BINARY LOGS 输出里的 File_size 列做交叉验证。
