17370845950

MySQL主从迁移需分四阶段：一评估现状（版本、复制方式、延迟等）；二部署新环境并同步数据；三无感切换（锁表、切流量、启复制）；四验证一致性与稳定性。

迁移 MySQL 主从架构不是简单地搬数据，核心是保障复制链路不断、数据一致、服务不中断。关键在于分阶段操作：先评估现状，再搭建新环境，接着平滑切换，最后验证收尾。

一、迁移前必须摸清当前主从状态

不清楚现有架构细节，迁移极易出错。重点确认以下几点：

• 主库和从库的 MySQL 版本（如 5.7 → 8.0 需注意兼容性与认证插件变更）
• 复制方式（基于 binlog 的传统异步复制？GTID？半同步？MGR？）
• 主从延迟情况（执行 SHOW SLAVE STATUS\G 查看 Seconds_Behind_Master 和 SQL_Delay）
• 是否存在过滤规则（replicate-do-db、binlog-do-db 等）
• 主库是否开启 log_bin、server_id 是否唯一、从库是否启用了 read_only=ON

二、新环境部署与数据同步准备

推荐使用物理备份 + binlog 追平方式，兼顾速度与一致性：

• 在主库上用 mysqldump --single-transaction --master-data=2 或 Percona XtraBackup 做一致性快照
• 将备份恢复到新主库，并确保 server_id 不同、gtid_mode 与原环境一致（若启用 GTID，需同时设置 enforce_gtid_consistency=ON）
• 新从库可先指向旧主同步，或直接从新主拉取（取决于切换策略）
• 若跨版本迁移（如 5.7→8.0），务必提前在测试环境验证 SQL 兼容性、字符集、密码认证插件（caching_sha2_password vs mysql_native_password）

三、业务无感切换的关键步骤

避免停机，需控制写入、等待同步、原子切换：

• 在旧主库执行 FLUSH TABLES WITH READ LOCK，记录当前 binlog 位置（SHOW MASTER STATUS）
• 暂停应用写入（可通过中间件/配置中心下线写流量，或临时修改 DNS/负载均衡指向只读）
• 等所有从库 Seconds_Behind_Master = 0 后，停止旧从库的复制：STOP SLAVE
• 将新主库的 CHANGE MASTER TO 指向旧主最后位置（或通过 GTID 自动定位），启动复制：START SLAVE
• 确认新主从同步正常后，把应用写请求切到新主库，再逐步放开读流量

四、迁移后必须验证的事项

切完不等于成功，要快速验证稳定性与数据正确性：

• 检查新主库的 SHOW PROCESSLIST 中是否有大量写入阻塞
• 对比新旧主库的表行数（SELECT COUNT(*) 抽样关键表）、校验 checksum（如 pt-table-checksum）
• 监控新主从的 Seconds_Behind_Master、Slave_IO_Running、Slave_SQL_Running 状态
• 观察慢查询日志、连接数、QPS 是否异常，确认性能未劣化
• 保留旧主库至少 48 小时只读运行，作为回滚兜底；确认无误后再下线

不复杂但容易忽略细节，尤其 GTID 模式下 RESET MASTER 和 SET GTID_PURGED 的配合、跨版本权限表初始化、时区与 SQL mode 差异，都可能引发复制中断或数据偏差。