异步迁移首选主从复制而非mysqldump，因其支持“边写边迁”：mysqldump需锁表导致业务阻塞，而主从复制通过binlog实时捕获变更、从库异步回放，不阻塞源库写入，满足低RPO、分钟级延迟要求。
为什么异步迁移首选主从复制而不是mysqldump
因为异步迁移的核心诉求是“边写边迁”，而mysqldump本质是快照式逻辑导出，必须加锁（如FLUSH TABLES WITH READ LOCK）才能保证一致性，哪怕只锁几秒，在高并发写场景下也会触发业务超时。主从复制则完全不阻塞源库写入——它靠binlog实时捕获变更，从库异步回放，天然支持持续同步。
常见错误现象：用mysqldump做“伪异步”（比如每小时跑一次），结果发现两次 dump 之间产生的数据全丢了；或者在 dump 过程中业务写入卡顿，监控看到大量 Waiting for table flush 等待事件。
- 适用场景：需要低RPO（接近0丢失）、允许分钟级延迟、目标仍是MySQL
- 不适用场景：跨数据库类型（如MySQL→PostgreSQL）、源库未开启
binlog、或binlog_format为STATEMENT且存在非确定性函数 - 性能影响：主库仅多一个
binlog dump线程，网络带宽占用可控；从库SQL线程单线程回放是瓶颈，可通过并行复制（slave_parallel_workers > 0）缓解
配置主从复制前必须确认的5个关键点
漏掉任意一项，复制启动后大概率报错中断，且错误信息往往藏在SHOW SLAVE STATUS\G的Seconds_Behind_Master或Last_IO_Error字段里，排查耗时远超预防成本。
- 源库必须启用
binlog：检查my.cnf中log-bin已开启，且server-id非0 -
binlog_format建议设为ROW：避免STATEMENT模式下NOW()、UUID()等函数导致主从数据不一致 - 创建专用复制账号，最小权限即可：
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY 'pwd'; - 目标库
server-id不能与源库重复，否则复制链路无法建立 - 若涉及跨版本（如MySQL 5.7→8.0），需确认
default_authentication_plugin兼容性，否则CHANGE MASTER TO会报ERROR 2003
如何安全切换到新库而不丢数据
主从追平后直接切流量，是最常见的翻车点。真正安全的切换不是看Seconds_Behind_Master = 0，而是要确认“最后一条事务已落地+后续无新写入”。
- 先在源库执行
FLUSH LOGS，生成最新binlog文件，再查SHOW MASTER STATUS拿到当前File和Position - 停写源库（比如关闭应用写入口），立即执行
SHOW MASTER STATUS二次确认位置未变 - 在从库执行
SELECT MASTER_POS_WAIT('mysql-bin.000001', 123456789)，返回非NULL值才代表该位点已同步完成 - 切流量前，务必在从库
SET GLOBAL read_only = OFF，否则应用连接会因只读报错 - 切换后立刻在新库
SELECT COUNT(*)比对关键表行数，并抽样校验几条带时间戳的记录是否最新
增量同步阶段最容易被忽略的细节
全量同步完成后进入增量阶段，看似自动运行，但relay log堆积、网络抖动、从库慢查询都会让复制 silently 滞后，直到业务投诉才暴露。
- 监控项不能只看
Seconds_Behind_Master：该值在从库重启后重置为0，但实际可能刚追上就又落后了；应同时监控Relay_Log_Space是否持续增长 - 避免在从库执行
ALTER TABLE：DDL会阻塞SQL线程，且ROW模式下可能引发主从结构不一致 - 如果从库有业务读请求，务必关闭
innodb_lock_wait_timeout的默认值（50秒），防止长事务拖垮复制线程 - 定期清理
relay log：设置relay_log_purge = ON，否则磁盘爆满会导致复制中断
异步迁移真正的复杂点不在启动那一刻，而在“持续同步”期间的静默状态——它不报错，但可能每天慢10秒，一个月后就差5分钟，切流时才发现订单对不上。盯住Relay_Log_Space和Exec_Master_Log_Pos这两个指标，比任何告警都管用。
