主从复制（Replication）是所有高可用方案的地基
几乎所有 MySQL 高可用方案都依赖二进制日志（
binlog）同步机制。主库写入变更后生成
binary log events，从库通过
I/O thread拉取并写入
relay log，再由
SQL thread重放——这就是经典异步复制链路。 必须开启
log-bin，且主从
server-id绝对不能重复
GTID模式（MySQL 5.6+）强烈推荐，避免手动找
File/Position，切换更可靠 常见翻车点：
slave_sql_running: No往往是主从表结构不一致或从库执行了 DML；
seconds_behind_master持续增长说明从库 IO 或磁盘慢，不是网络问题 不要在从库写入数据——除非你已用
read_only=ON+
super_read_only=ON双锁死
InnoDB Cluster（MGR）适合需要自动选主和强一致的中小规模业务
MySQL 官方 5.7.17+ 提供的
Group Replication（MGR）是基于 Paxos 协议的多节点共识机制，天然支持单主/多主模式，故障后秒级自动切换，无需外部工具干预。 必须使用
ROW格式 binlog（
binlog_format=ROW），否则事务无法校验
enforce_gtid_consistency=ON和
gtid_mode=ON是硬性前提 节点间网络延迟必须稳定 ≤ 100ms，否则频繁踢出节点（
MEMBER_STATE=UNREACHABLE） 别跳过
MySQL Router直连节点——它是唯一能感知集群状态并自动路由到当前主库的代理
CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_HOST='cluster-node-1', MASTER_PORT=3306, GET_MASTER_PUBLIC_KEY=1;
DRBD + Heartbeat / Keepalived 是“类 SAN”但成本更低的双机热备方案
DRBD 不同步 SQL 日志，而是直接镜像整个块设备（
/dev/sdb），主库写磁盘前强制同步到备机，故障时 VIP 漂移 + 文件系统重新挂载即可启动 MySQL——数据零丢失，但仅限两节点。 DRBD 同步模式必须设为
protocol C（同步写），否则有丢数据风险 Heartbeat 已基本被
Keepalived替代，后者轻量、配置直观，配合
notify_master脚本可自动启停 MySQL 注意：DRBD 无法跨数据中心，两地三中心场景必须用异步复制+人工干预 升级 MySQL 版本前务必先停 DRBD，否则元数据不兼容直接导致脑裂
MHA 和 Orchestrator 这类工具只解决“故障发现+切换”，不解决数据一致性
MHA（Master High Availability）是 Perl 写的老牌切换工具，能在 10–30 秒内完成主从提升，但它本身不保证从库没延迟、不校验 GTID、也不管你有没有未提交事务。现在更推荐
Orchestrator（Go 编写，带 Web UI）或
ProxySQL + 自动化脚本。 MHA 的
master_ip_failover_script必须自己写，否则 VIP 不会漂移 切换后务必检查新主库的
Executed_Gtid_Set是否包含旧主库最后的事务，否则可能丢写 别在 MHA 环境里混用半同步（
rpl_semi_sync_master_enabled），它和 MHA 的 failover 逻辑有冲突 如果业务允许几秒延迟，用
ProxySQL + read/write hostgroup做读写分离比折腾 MHA 更稳 真正决定方案成败的，往往不是选哪个架构，而是**是否统一了 MySQL 版本、是否禁用了危险 SQL（如
CREATE TEMPORARY TABLE）、是否定期验证备份可恢复、以及是否把监控嵌进了切换流程**——这些细节比“集群”二字重要得多。
