MySQL主从复制需以GTID保障一致性，用mysqldump--single-transaction导出并SOURCE_AUTO_POSITION=1启动；监控须结合IO/SQL线程状态、GTID集合差值及pt-heartbeat；从库设read_only+权限控制防误写；故障切换依赖MHA等自动化工具，且需验证GTID覆盖与新主写入能力。
在项目中使用 MySQL 主从复制，核心目标是提升读写分离能力、增强数据可用性与容灾能力。但实际落地时，不能只配好 binlog 和 relay log 就完事——配置只是起点，稳定运行、故障识别、数据一致性保障才是关键。
主从搭建不是“配完就跑”，重点在初始化一致性
很多团队直接 mysqldump 导出主库再导入从库，却忽略锁表或 GTID 模式不一致导致的同步中断。推荐做法：
- 主库开启 GTID（
gtid_mode=ON+enforce_gtid_consistency=ON），避免位点偏移问题 - 用 mysqldump --single-transaction --master-data=2 --flush-logs 导出，确保快照一致性且记录准确 binlog 位置
- 从库恢复后，用
CHANGE MASTER TO ... SOURCE_AUTO_POSITION = 1;启动复制，靠 GTID 自动对齐，不依赖手动指定 file/position
监控不能只看 Seconds_Behind_Master
这个值为 0 不代表一切正常——它可能因网络抖动归零，也可能因从库 SQL 线程卡死而长时间不变。必须组合观察：
-
SHOW SLAVE STATUS\G中关注：Slave_IO_Running 和 Slave_SQL_Running 是否均为 Yes - 检查 Retrieved_Gtid_Set 和 Executed_Gtid_Set 是否持续增长且差值稳定（差值突增说明堆积）
- 配合 pt-heartbeat 工具写入心跳表，实测端到端延迟，比 Seconds_Behind_Master 更真实
写操作误发到从库？必须物理+逻辑双拦截
从库被应用直连写入是主从失效头号原因。光靠权限控制不够：
- 从库设置 read_only=ON（注意：需 SUPER 权限用户仍可写，所以要搭配账号权限限制）
- 应用层明确区分 write datasource 和 read datasource，禁止在读库执行 INSERT/UPDATE/DELETE
- 中间件如 ShardingSphere 或 MyCat 可强制路由，或在数据库代理层（如 ProxySQL）配置规则拦截写请求
主库宕机后切换不能靠“人肉判断”
手动改 DNS 或改应用配置耗时长、易出错。生产环境应有自动化方案：
- 用 MHA 或 Orchestrator 实现自动故障检测 + 主从提升 + VIP 切换
- 切换前确认从库 Executed_Gtid_Set 完全覆盖主库（防止丢数据），必要时跳过事务需谨慎评估
- 切换后立即验证新主库的写入能力，并检查原主库恢复后能否作为从库重新接入（GTID 模式下通常可自动追平）
主从复制不是一劳永逸的配置项，而是需要持续观测、定期演练、结合业务节奏迭代的运维能力。配置正确只是门槛，真正考验的是对异常模式的敏感度和快速响应机制。
