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