MySQL主从复制需按业务需求定制：读多写少用异步+多从，强一致选半同步，高可用需MGR或GTID多源复制；务必启用GTID与ROW格式，区分从库角色，强化监控与自动切换。
MySQL 主从复制不是“选不选”的问题，而是“怎么配才稳、才快、才可维护”的问题。核心在于匹配业务读写特征、数据一致性要求和运维能力，而不是盲目套用标准模式。
先看业务真实需求：读多写少？强一致？还是容灾优先？
不同场景下，主从模式的侧重点完全不同：
- 报表类、后台管理类系统——读请求远大于写，且能容忍秒级延迟 → 异步复制 + 多从库负载均衡 是最常用也最经济的选择
- 金融类、订单类核心链路——写后立刻要读到最新结果（如支付成功查订单状态）→ 必须引入 半同步复制（semisync），并配合应用层的读写分离路由策略（比如写后强制走主库查一次）
- 跨机房高可用要求高（如同城双活）→ 单纯主从不够，需结合 MGR（MySQL Group Replication） 或 基于GTID的多源复制+自动故障切换，但对网络稳定性和DBA能力要求明显提高
别只盯“同步/异步”，GTID 和 binlog 格式才是底层关键
是否启用 GTID（Global Transaction Identifier）会极大影响复制管理效率和故障恢复速度：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 用 GTID 模式：跳过事务、重搭从库、定位主从差异都更可靠；建议新集群默认开启，且 binlog_format 必须设为 ROW（避免语句级复制导致的主从不一致）
- 不用 GTID：靠 file + position 管理复制点，易出错，尤其在主库重启、binlog 清理或人为跳过事件时；仅适合极简小系统或历史遗留环境
- 注意：MIXED 或 STATEMENT 格式在主从不一致风险上远高于 ROW，除非有明确兼容性原因，否则不要用
从库不止用来读，还要考虑它的真实角色
一个从库可以承担多种职责，但不能同时过度压榨：
- 只读从库：专注分担查询压力，建议关闭 query_cache（已弃用）、禁用非必要监控插件，降低干扰
- 备份从库：单独部署一台，延迟拉大（比如设置 replicate_do_db + 延迟 3600 秒），专用于误操作回滚；记得定期校验其数据一致性（pt-table-checksum）
- 分析型从库：加列、建冗余索引、跑慢查询都不影响主库；但要注意长事务可能阻塞 purge 线程，需监控 innodb_trx 和 slave_sql_running_state
监控和切换机制比复制本身更重要
复制延迟、IO/SQL 线程中断、主键冲突、duplicate key 错误……这些问题每天都在发生。光配好没用，得能及时发现、安全干预：
- 必须监控：Seconds_Behind_Master（注意它可能为 0 却实际卡住）、Slave_IO_Running / Slave_SQL_Running、Retrieved_Gtid_Set vs Executed_Gtid_Set 差值
- 主库宕机时，不能靠人工判断谁来顶上——要么用 Orchestrator / MHA 这类成熟工具做自动故障转移，要么在应用层实现带健康检查的连接池（如 ShardingSphere、ProxySQL）
- 每次主从切换后，务必验证：新主库的 read_only 是否关闭、GTID_EXECUTED 是否完整、从库是否重新指向正确主库
不复杂但容易忽略：主从复制不是一劳永逸的配置，它是持续演进的数据链路。从第一次建从库开始，就要想清楚它未来半年会不会升级成 MGR，能不能扛住流量翻倍，以及 DBA 能不能在凌晨三点快速定位一条复制中断的原因。
