MySQL主从复制、读写分离与高可用是环环相扣的整体：主从基于binlog异步重放，存在延迟；读写分离需兼顾事务一致性，强读必须走主库；高可用须防脑裂，依赖GTID、仲裁节点及精准故障判断。
MySQL 的数据同步、读写分离和高可用不是三个独立功能，而是一套环环相扣的运维实践组合——没做对主从同步，读写分离就不可靠；没做好故障切换机制，高可用就是空谈。
主从复制（CHANGE MASTER TO 和 START SLAVE 是关键）
MySQL 主从复制本质是基于 binlog 的日志重放，不是实时镜像。从库 IO 线程拉取主库 binlog，SQL 线程回放事件，两者异步运行，天然存在延迟。
-
SHOW SLAVE STATUS\G中的Seconds_Behind_Master为NULL可能表示 SQL 线程已停止，不一定是延迟为 0 - 使用 GTID 模式（
gtid_mode=ON）可避免传统复制中因Relay_Log_File偏移错位导致的同步中断 - 主库写入压力大 + 从库单线程回放（5.6 默认）易造成积压，5.7+ 开启
slave_parallel_workers可缓解 - 误操作执行
DROP TABLE后，binlog 若未开启binlog_format=ROW，可能无法精确闪回
读写分离不能只靠中间件（maxscale / mycat / 应用层路由）
中间件只是流量分发器，它不感知业务语义。一个事务里先写后读，若读被路由到从库，大概率读不到刚写的数据。
- 强一致性读必须直连主库，常见做法是在 SQL 注释中标记：
/*#master*/ SELECT ... - 应用层实现读写分离时，需在事务开启（
BEGIN）后自动将后续所有查询路由至主库，直到COMMIT或ROLLBACK -
maxscale的readwritesplit模块默认不解析事务边界，需配合transaction_replay=on或应用显式标记 - 从库延迟超过阈值（如 3 秒）应自动剔除出读池，避免脏读——这需要监控脚本持续调用
SHOW SLAVE STATUS并更新后端列表
高可用 ≠ 自动切主（mysqlfailover 已弃用，orchestrator / mha 更现实）
自动故障转移最大的风险不是切不成功，而是脑裂：网络分区导致旧主未真正宕机却继续提供写入，新主也已上线，数据从此分裂。
- MHA 要求 SSH 免密 +
master_ip_failover脚本接管 VIP，但 0.57 版本后不再维护，生产环境慎用 - orchestrator 支持多数据中心拓扑探测，但依赖后端 MySQL 实例开启
performance_schema，否则无法准确判断主库是否存活 - 任何高可用方案都必须配合仲裁节点（如 etcd 或至少第三个独立网络点），仅靠两个 MySQL 实例心跳无法解决脑裂
- 切主后从库重建（
CHANGE MASTER TO MASTER_AUTO_POSITION=1）比传统 file/pos 方式更安全，但要求所有节点enforce_gtid_consistency=ON
真正难的从来不是配置命令，而是理解每条 CHANGE MASTER TO 背后的日志位点含义，以及在 Seconds_Behind_Master 跳变为 NULL 时，第一反应不是重启 slave_sql，而是查 Last_SQL_Error —— 那才是问题真正的入口。
