如何迁移mysql主从架构_mysql架构迁移方案

18次阅读

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

如何迁移mysql主从架构_mysql架构迁移方案

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

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

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

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

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

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

  • 在主库上用 mysqldump --single-transaction --master-data=2Percona 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_MasterSlave_IO_RunningSlave_SQL_Running 状态
  • 观察慢查询日志、连接数、QPS 是否异常,确认性能未劣化
  • 保留旧主库至少 48 小时只读运行,作为回滚兜底;确认无误后再下线

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

text=ZqhQzanResources