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 “当时”写入的位置。
WOC是基于zend framework1.6框架所开发的一款开源简易网站运营管理系统。它允许进行网站管理、主机管理、域名管理、数据库管理、邮箱管理以及用户管理、角色管理、权限管理等一系列功能，适合中小企业进行网站运营管理。目前版本为V1.2，新版本正在开发中，同时欢迎大家参与到开发中来！ WOC升级说明： 1.1在1.0的基础上进行了代码规范并增加了配置数据缓存，以提高访问速度 注意：升级时要重
真正的问题常藏在细节里：
- 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 的价值不在“高大上”，而在降低运维动作出错概率——尤其是故障恢复和架构调整时，少一次手抖，就少一次数据不一致。
