MySQL双机热备（主从复制）不是开箱即用的高可用方案，必须配合外部工具或严谨策略才能落地；其三大硬性前提是：server-id全局唯一、从库版本≥主库、初始数据严格一致，缺一不可。
MySQL双机热备（主从复制）不是开箱即用的高可用方案，它本身不自动切换、不感知故障、不解决脑裂，必须配合外部工具或严谨策略才能落地为可用架构。直接只配 CHANGE MASTER TO + START SLAVE，离“高可用”还差很远。
主从配置前必须统一的三个硬性前提
很多同步失败、数据不一致、启动报错，根源都在这三处没对齐：
-
server-id必须全局唯一：两台机器不能相同，也不能为 0；建议用 IP 最后一段或自定义数字（如server-id = 101、server-id = 102） - MySQL 版本需兼容：从库版本 ≥ 主库版本；5.7 主库配 5.6 从库会报
Unknown system variable 'gtid_mode'类错误 - 初始数据必须一致：仅靠复制不拉取历史数据；若主库已有业务表，必须先
mysqldump --single-transaction --master-data=2导出，再导入从库，否则SHOW SLAVE STATUS\G中Seconds_Behind_Master永远为NULL或报错
binlog 格式与复制模式的选择直接影响一致性
默认 STATEMENT 模式在非确定性函数（如 NOW()、UUID()、sysdate()）下会导致主从数据偏差；生产环境应强制使用 ROW 或 MIXED：
在 /etc/my.cnf 的 [mysqld] 段添加：
binlog-format = ROW log-bin = mysql-bin expire_logs_days = 7
注意：ROW 模式日志体积更大、网络带宽占用高，但能精确还原每一行变更；若用 GTID 复制（推荐），还需开启：
gtid_mode = ONenforce_gtid_consistency = ON- 两台都设
log_slave_updates = ON（双向复制或级联场景必需）
从库启动复制时最常踩的三个坑
START SLAVE 后 Slave_IO_Running 或 Slave_SQL_Running 为 No，基本就卡在这几个点：
- 主库防火墙未放行 3306 端口，或
bind-address绑定为127.0.0.1，导致从库连不上 —— 改成0.0.0.0或具体内网 IP - 复制用户权限不足：必须显式授予
REPLICATION SLAVE，且 host 要匹配从库真实出口 IP（不是%，尤其跨 NAT 时）；执行完GRANT务必FLUSH PRIVILEGES -
CHANGE MASTER TO中的MASTER_LOG_FILE和MASTER_LOG_POS错了：必须来自主库执行SHOW MASTER STATUS\G的**实时输出**，不是配置文件里写的文件名；若主库重启过、或 binlog 被 purge，这里极易出错
主从延迟和写入冲突是热备架构里最隐蔽的风险点
从库延迟不是“慢一点”，而是“不可控地丢数据”的前兆：
- 监控不能只看
Seconds_Behind_Master：该值在 SQL 线程卡住时可能为 0，实际已落后；应结合Relay_Master_Log_File与Exec_Master_Log_Pos对比主库当前 binlog 位置 - 从库禁止写入是铁律：一旦在从库执行
INSERT/UPDATE，后续主库同表同主键写入会触发Duplicate entry或跳过错误，导致数据永久不一致 - 自增主键必须错开：双主场景下，务必设
auto_increment_offset和auto_increment_increment（如主 A 设 offset=1, inc=2；主 B 设 offset=2, inc=2），否则 failover 后插入冲突
真正关键的不是“能不能同步”，而是“同步错了能不能及时发现、有没有回滚路径”。没有定期校验（如 pt-table-checksum）、没有延迟告警、没有只读开关的主从，只是个单点故障放大器。
