17370845950

MySQL主从复制基于binlog+relay log异步重放，需ROW格式、开启log-bin、唯一server-id；GTID提升切换可靠性但须全集群统一启用；延迟监控须结合Seconds_Behind_Master与File/Position比对。

主从复制靠的是 binlog + relay log 两级日志流转

MySQL 主从复制不是实时内存同步，而是基于日志的异步（或半同步）重放。主库把所有写操作记录到 binlog，从库通过 I/O 线程拉取并存为 relay log，再由 SQL 线程顺序执行其中的事件。

关键点在于：binlog 格式必须为 ROW 或 MIXED（不推荐 STATEMENT，因函数、临时表、非确定性语句易导致主从不一致）；主库需开启 log-bin，从库需设置 server-id 且唯一。

• binlog_format = ROW 是生产环境事实标准，能精确捕获行级变更
• 从库的 relay_log 文件默认命名规则是 hostname-relay-bin.xxxxxx，不建议手动修改其路径，否则 CHANGE MASTER TO 可能失效
• SQL 线程单线程回放 relay log，这是传统主从的性能瓶颈，MySQL 5.7+ 的 slave_parallel_workers > 0 可按库/事务分发，但需配合 slave_parallel_type = LOGICAL_CLOCK

START SLAVE 启动失败常见原因和检查项

执行 START SLAVE 后，SHOW SLAVE STATUS\G 中 Slave_IO_Running 或 Slave_SQL_Running 为 No，说明链路中断。不能只看 Seconds_Behind_Master 是否为 NULL。

• IO 线程失败：检查主库网络可达性、复制用户权限（REPLICATION SLAVE）、主库 binlog 文件是否被清理（show master logs 对比 Master_Log_File）、主库磁盘满导致 binlog 写入失败
• SQL 线程失败：最常见于主从数据不一致引发的唯一键冲突、表结构不一致（如从库少字段）、DDL 执行失败（如 DROP TABLE 在从库不存在）、或 binlog_format = STATEMENT 下调用 NOW() / UUID() 导致时间/值不一致
• 跳过错误需谨慎：SET GLOBAL sql_slave_skip_counter = 1 仅对 STATEMENT 格式有效；mysqlbinlog --stop-never 解析 relay log 定位具体出错 SQL 更可靠

GTID 模式让主从切换更可控，但要求全集群统一开启

启用 GTID（gtid_mode = ON + enforce_gtid_consistency = ON）后，每个事务有全局唯一标识，不再依赖 File/Position。故障切换时，新主库可直接告诉从库“从这个 GTID 集合之后开始同步”，避免找错 binlog 偏移量。

• GTID 开启必须重启 MySQL 实例，且主从必须同时开启，混合模式不可行
• 使用 CHANGE MASTER TO MASTER_AUTO_POSITION = 1 替代手工指定 MASTER_LOG_FILE 和 MASTER_LOG_POS
• GTID 不保证事务执行顺序完全一致（例如跨库并发事务在主库提交顺序与从库回放顺序可能不同），但能确保最终一致性
• 慎用 RESET MASTER：它会清空所有 binlog 并重置 GTID_EXECUTED，若从库尚未消费完，会导致无法继续同步

主从延迟大不只是网络问题，要盯住 Seconds_Behind_Master 的真实含义

Seconds_Behind_Master 显示的是 SQL 线程执行位置距离当前时间的秒数，不是 IO 线程拉取延迟。它为 0 仅表示“已执行完当前 relay log 中所有事件”，不代表没有积压——如果 IO 线程卡住，这个值可能长时间为 0，但实际已落后。

• 真正判断延迟要看：Relay_Master_Log_File 和 Exec_Master_Log_Pos 是否追上主库的 File/Position（用 SHOW MASTER STATUS 对比）
• 大事务是最大延迟源：一个耗时 30 分钟的 UPDATE 在从库单线程回放，就会卡住后续所有事务
• 从库负载过高（如慢查询、备份、统计分析）也会拖慢 SQL 线程，建议从库关闭 query_cache_type，避免缓存锁竞争
• 监控不能只看 Seconds_Behind_Master，应结合 Seconds_Behind_Master IS NULL（线程异常）、Retrieved_Gtid_Set 与 Executed_Gtid_Set 差集大小（GTID 模式下更准）

SELECT 
  @@global.gtid_mode AS gtid_mode,
  @@global.enforce_gtid_consistency AS enforce_gtid_consistency,
  @@global.binlog_format AS binlog_format,
  @@global.log_bin AS log_bin;

主从复制看似配置简单，但 binlog 格式、GTID 开关时机、SQL 线程卡点、以及监控指标的真实含义，这几处一旦设错或忽略，高可用就变成高不可靠。