MySQL主从复制中，master负责写入并记录变更到binlog，slave通过IO Thread拉取binlog写入relay log，再由SQL Thread重放事件；生产推荐ROW格式binlog以保障一致性；延迟本质是执行位置差，GTID提升切换与运维可靠性。

MySQL 主从复制中 master 和 slave 各自承担什么职责

master 负责写入和记录变更，slave 负责读取并重放这些变更。这不是简单的“备份”，而是基于二进制日志（binlog）的异步事件流消费机制。

master 上每个事务提交后，会把操作以事件形式写入 binlog（需开启 log-bin）；slave 的 IO Thread 连接 master，拉取 binlog 内容并写入本地的 relay log；随后 SQL Thread（或 Worker Threads，在并行复制下）解析并执行这些事件。

• master 不感知 slave 是否在线、是否延迟，只要 binlog 未被清理就可被拉取
• slave 的 IO Thread 和 SQL Thread 状态需分别检查：SHOW SLAVE STATUS\G 中的 Slave_IO_Running 和 Slave_SQL_Running
• 若 SQL Thread 报错（如主键冲突、表不存在），复制会中断，必须人工干预（SET GLOBAL sql_slave_skip_counter = 1 或 pt-slave-restart）

binlog 格式如何影响数据同步的准确性与兼容性

MySQL 支持 STATEMENT、ROW、MIXED 三种 binlog_format，直接决定 slave 重放时的行为逻辑和一致性保障程度。

STATEMENT 记录的是原始 SQL，但函数（如 NOW()、UUID()）、用户变量、非确定性语句（如 ORDER BY 配合 LIMIT）在 slave 上执行可能产生不同结果；ROW 记录每一行变更前后的镜像，精确但体积大、对 DDL 不直接记录（依赖 binlog_row_image 控制）；MIXED 是自动切换模式，但切换逻辑不透明，调试困难。

• 生产环境强烈建议使用 ROW：避免因函数/时序导致主从不一致
• 启用 ROW 后，注意 binlog_row_image = FULL（默认值），否则 MINIMAL 或 NOBLOB 可能导致更新丢失字段
• STATEMENT 在跨版本复制（如 MySQL 5.7 → 8.0）中容易因语法差异失败，ROW 兼容性更好

复制延迟的本质原因与常见误判点

延迟不是网络卡顿的简单体现，而是 Seconds_Behind_Master 字段反映 slave 当前执行位置与 master 当前 binlog 位置之间的时间差——这个值为 0 并不等于实时，它只说明 slave 已追上 master “当时”写入的位置。

真正的问题常藏在细节里：

• master 上大事务（如 ALTER TABLE、全表 UPDATE）会生成巨大 binlog 事件，slave 的 SQL Thread 单线程串行执行，必然积压
• slave 的磁盘 I/O 慢（尤其 relay log 和数据目录在同一慢盘）、CPU 不足、或开启了 sync_binlog = 1 + innodb_flush_log_at_trx_commit = 1 会拖慢重放速度
• Seconds_Behind_Master 在 slave 复制中断时可能显示 NULL，此时不能用它判断延迟，而要看 Read_Master_Log_Pos 和 Exec_Master_Log_Pos 是否相等

GTID 复制相比传统 file+pos 复制解决了哪些实际问题

传统复制靠 Master_Log_File 和 Read_Master_Log_Pos 定位，一旦 master 发生故障切换，手动找 pos 极易出错；GTID（Global Transaction Identifier）让每个事务自带唯一 ID（source_id:transaction_id），slave 只需记录已执行哪些 GTID，切换、跳过、校验都变得可编程。

启用 GTID 后，CHANGE MASTER TO 不再需要指定文件名和位置，改用 MASTER_AUTO_POSITION = 1；且 gtid_executed 和 gtid_purged 自动维护，避免因 binlog 清理导致的同步断裂。

• 必须同时设置 gtid_mode = ON 和 enforce_gtid_consistency = ON，后者会拒绝不安全语句（如含 CREATE TEMPORARY TABLE 的事务）
• GTID 复制下，RESET MASTER 会清空 gtid_purged，若 slave 尚未拉取全部事务，会导致无法继续同步
• 主从切换后，新 master 的 gtid_purged 必须包含旧 master 的全部 GTID，否则 slave 会报错 The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires

SET GLOBAL gtid_mode = ON;
SET GLOBAL enforce_gtid_consistency = ON;

GTID 的价值不在“高大上”，而在降低运维动作出错概率——尤其是故障恢复和架构调整时，少一次手抖，就少一次数据不一致。