主从复制能直接当迁移方案用吗？
不能。主从复制本身只是数据同步机制，不是迁移工具——它不处理应用连接切换、DDL 阻塞、从库角色转换、GTID 一致性校验等迁移必需环节。强行把 CHANGE MASTER TO 配完就切流量，90% 会出数据错乱或连接中断。
真正可用的“零停机迁移”，是主从复制 + 应用层灰度 + 切换控制脚本 + 校验兜底组成的闭环，核心目标不是“不停”，而是“可退、可查、可控”。
如何让从库具备随时接管能力？
关键在三件事：GTID 必开、从库只读必须显式关闭、复制延迟要实时可监控。
-
gtid_mode=ON和enforce_gtid_consistency=ON必须在主从两端同时生效，否则切换后无法可靠定位事务位置 - 从库默认
read_only=ON，但应用直连时会报ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement；切流前需临时执行SET GLOBAL read_only = OFF（注意：仅限切换窗口期，切完立刻关） - 别信
Seconds_Behind_Master—— 它在并行复制下常为 0 却实际积压；改用SELECT MASTER_POS_WAIT('xxx', xxx, 2)或解析SHOW SLAVE STATUS中的Retrieved_Gtid_Set与Executed_Gtid_Set差集来判断真实追平状态
应用连接怎么切才不丢请求？
靠 DNS 或 VIP 切换？太慢，且中间件/客户端缓存会让部分请求打到旧主库。最稳的方式是双写+读分离+开关控制，分三步走：
- 先让新从库承担全部读流量（确认
slave_sql_running=Yes且无延迟），主库只写 - 上线配置开关（如 Redis key
migration:write_target），初始值为old；所有写请求先发旧主，再异步发新主（用INSERT ... ON DUPLICATE KEY UPDATE或幂等日志兜底） - 校验新主数据一致后，原子性地把开关改为
new，旧主停止写入；5 分钟内观察错误日志里是否还有Deadlock found when trying to get lock或Lock wait timeout exceeded—— 有说明双写未完全收敛
为什么 mysqldump + binlog 补丁不如主从延时从库？
因为 dump 期间锁表或 FTWRL 会卡住业务 DML，哪怕加 --single-transaction，对大表 ALTER TABLE 或长事务仍可能触发复制中断。而基于主从的迁移，所有操作都在从库完成，主库完全无感。
但要注意：如果原主库开了 binlog_format=STATEMENT，某些函数（如 NOW()、UUID()）会导致从库数据和主库不一致；必须提前改成 MIXED 或 ROW，并检查 SHOW BINARY LOGS 是否有 warning 级别事件。
真正难的从来不是配通复制，而是确认「此刻从库的数据，就是主库当前时刻该有的样子」——这需要你亲手比对几条关键业务记录的 GTID_EXECUTED，而不是相信监控面板上那个绿色的 “Running”。
