MySQL主从复制本身不提供强一致性，需通过GTID、read_only、半同步等架构设计与运维约束实现事务最终一致性；主库必须开启log-bin且server-id唯一，从库须设read_only=ON并用SOURCE_AUTO_POSITION=1启用GTID自动定位，同时持续监控Seconds_Behind_Master和GTID集合差异。
MySQL 主从复制本身不提供强一致性，读写分离下的“事务最终一致性”是靠架构设计+运维约束达成的，不是配置开关能一键开启的。关键在于：**主从延迟不可消除，但可监控、可收敛、可规避**。
主库必须开 log-bin 且 server-id 唯一，否则复制链路直接断掉
这是最基础也最容易翻车的一步。漏掉 log-bin 或者多个实例用了同一个 server-id=1，从库连 CHANGE MASTER TO 都会报错 ERROR 2003 (HY000): Can't connect to MySQL server 或更隐蔽的 Slave_IO_Running: No。
-
log-bin必须写在[mysqld]段下，推荐用相对路径如log-bin=mysql-bin，避免绝对路径权限问题 -
server-id别硬编码为 1/2，用 IP 末段（如192.168.88.53 → server-id=53）更安全 - MySQL 8.0+ 默认
binlog_format=ROW，别手动改成STATEMENT——后者在函数、临时表、非确定性语句下极易导致主从不一致
从库必须设 read_only=ON，否则写请求打到从库就彻底乱套
很多线上事故不是复制失败，而是应用误发 UPDATE 到从库，或运维手抖执行了写操作。即使开了 read_only，也要注意：super_read_only=ON 才能阻止 super 用户写入（MySQL 5.7+ 默认关闭）。
- 仅靠中间件路由不能替代
read_only—— 中间件挂了、配置错了、绕过代理直连，都会失效 -
read_only不影响复制线程自身写入（SQL thread 有特殊权限），但会拦截所有外部写请求 - 验证是否生效：连上从库执行
SELECT @@read_only;，返回1才算到位
用 GTID 替代 FILE/POS 手动定位，避免位置错位导致跳事务
传统 CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000008', MASTER_LOG_POS=888 极易出错：主库 SHOW MASTER STATUS 和从库 CHANGE MASTER TO 时间差哪怕 1 秒，就可能漏掉事务。GTID 把每个事务打上唯一 ID，从库只管“我要同步到哪个 GTID”，不再依赖文件名和偏移量。
- 主从都必须启用：
gtid_mode=ON+enforce_gtid_consistency=ON - 从库执行：
CHANGE MASTER TO MASTER_HOST='xxx', ..., SOURCE_AUTO_POSITION = 1;（MySQL 8.0.23+ 推荐用SOURCE_AUTO_POSITION，旧版用AUTO_POSITION = 1） - GTID 下
RESET SLAVE会清空gtid_executed，务必先SELECT @@gtid_executed;记录当前值再重置
验证不能只看 Slave_IO_Running 和 Slave_SQL_Running
这两个字段显示 Yes 只代表线程活着，不代表数据没丢、没延迟、没卡住。真正要盯的是：
-
Seconds_Behind_Master：持续 > 0 就说明落后，> 60 秒就得查原因（网络抖动？从库磁盘慢？大事务阻塞 SQL thread？） -
Exec_Master_Log_Pos是否稳定增长：如果长期不动，可能是 SQL thread 卡在某条 DDL 或死锁 -
Retrieved_Gtid_Set和Executed_Gtid_Set是否相等：不等说明 IO thread 拉到了但 SQL thread 没执行完 - 定期跑
SELECT COUNT(*) FROM information_schema.processlist WHERE COMMAND='Query' AND STATE LIKE '%Locked%';查从库锁等待
