Mysql

关注公众号 jb51net

关闭
首页 > 数据库 > Mysql > MySQL不停机迁移

MySQL实现不停机迁移的完整指南

作者:就叫飞六吧

在生产环境中,数据库迁移是一个常见但充满挑战的任务,传统的停机迁移方式会导致业务中断,对于7×24小时运行的互联网服务来说,这种停机时间是不可接受的,所以本文给大家介绍了MySQL如何不停机迁移,需要的朋友可以参考下

一、为什么需要不停机迁移?

在生产环境中,数据库迁移是一个常见但充满挑战的任务。传统的停机迁移方式会导致业务中断,对于7×24小时运行的互联网服务来说,这种停机时间是不可接受的。不停机迁移方案可以在保证业务连续性的前提下,完成数据库的平滑迁移。

二、核心原理解析

不停机迁移的核心思想是:先全量复制,后增量同步。具体来说:

  1. 全量备份阶段: 使用mysqldump导出数据,并记录备份时刻的binlog位置
  2. 数据导入阶段: 将备份数据导入到新数据库
  3. 增量同步阶段: 通过主从复制机制,从记录的binlog位置开始同步增量数据
  4. 切换阶段: 数据追平后,切换应用连接到新数据库

这种方案的精妙之处在于:binlog作为增量数据的桥梁,确保了在备份期间和导入期间产生的新数据不会丢失。

三、详细实施步骤

3.1 准备工作

源库配置检查:

# 确认binlog已开启
mysql> SHOW VARIABLES LIKE 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+

# 查看binlog格式(建议ROW格式)
mysql> SHOW VARIABLES LIKE 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+

创建复制用户:

-- 在源库创建用于主从复制的专用账号
CREATE USER 'repl_user'@'新库IP' IDENTIFIED BY '强密码';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl_user'@'新库IP';
FLUSH PRIVILEGES;

3.2 全量备份并记录binlog位置

这是整个方案的关键步骤!

# 使用mysqldump导出数据,同时记录binlog位置
mysqldump -h源库IP -u用户名 -p \
  --single-transaction \
  --master-data=2 \
  --flush-logs \
  --routines \
  --triggers \
  --events \
  --all-databases \
  > full_backup.sql

# 参数说明:
# --single-transaction: 对InnoDB表使用一致性快照,不锁表
# --master-data=2: 在备份文件中注释形式记录binlog位置
# --flush-logs: 生成新的binlog文件,便于后续管理
# --routines: 导出存储过程和函数
# --triggers: 导出触发器
# --events: 导出事件调度器

查看备份文件中的binlog信息:

head -n 50 full_backup.sql | grep "CHANGE MASTER TO"
# 输出示例:
# -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000015', MASTER_LOG_POS=154;

记住这两个关键信息:

3.3 在新库导入数据

# 将备份文件传输到新服务器
scp full_backup.sql root@新库IP:/tmp/

# 在新库执行导入
mysql -h新库IP -u用户名 -p < full_backup.sql

# 或使用source命令(可显示导入进度)
mysql -h新库IP -u用户名 -p
mysql> source /tmp/full_backup.sql;

3.4 配置主从复制

在新库(从库)上配置主从关系:

-- 停止从库(如果之前有配置)
STOP SLAVE;

-- 配置主库信息
CHANGE MASTER TO
  MASTER_HOST='源库IP',
  MASTER_PORT=3306,
  MASTER_USER='repl_user',
  MASTER_PASSWORD='强密码',
  MASTER_LOG_FILE='mysql-bin.000015',  -- 使用备份时记录的文件名
  MASTER_LOG_POS=154;                  -- 使用备份时记录的位置

-- 启动主从复制
START SLAVE;

-- 检查复制状态
SHOW SLAVE STATUS\G

关键状态检查:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
             Slave_IO_Running: Yes  -- 必须是Yes
            Slave_SQL_Running: Yes  -- 必须是Yes
          Seconds_Behind_Master: 0   -- 延迟秒数,接近0说明快追平了

3.5 监控同步进度

# 持续监控延迟情况
watch -n 1 "mysql -u用户名 -p密码 -e 'SHOW SLAVE STATUS\G' | grep 'Seconds_Behind_Master'"

# 或使用SQL查询
SELECT 
  CONCAT(
    'IO线程: ', Slave_IO_Running, 
    ' | SQL线程: ', Slave_SQL_Running,
    ' | 延迟: ', Seconds_Behind_Master, '秒'
  ) AS 复制状态
FROM information_schema.REPLICA_STATUS;

3.6 切换应用连接

Seconds_Behind_Master接近0时,准备切换:

  1. 设置源库为只读(可选,更安全):
-- 在源库执行
SET GLOBAL read_only = ON;
SET GLOBAL super_read_only = ON;
  1. 最终确认数据一致性:
# 对比源库和新库的数据量
mysql -h源库IP -e "SELECT table_schema, COUNT(*) FROM information_schema.tables GROUP BY table_schema;"
mysql -h新库IP -e "SELECT table_schema, COUNT(*) FROM information_schema.tables GROUP BY table_schema;"
  1. 修改应用配置,指向新库:
# 应用配置文件示例
database:
  host: 新库IP
  port: 3306
  username: app_user
  password: app_password
  1. 重启应用或热更新配置
  2. 验证业务功能正常

3.7 收尾工作

-- 新库不再需要作为从库时,停止复制
STOP SLAVE;

-- 重置从库配置(可选)
RESET SLAVE ALL;

-- 关闭源库只读模式(如果需要保留源库)
SET GLOBAL read_only = OFF;
SET GLOBAL super_read_only = OFF;

四、核心优势

  1. 零数据丢失: binlog机制保证了从备份开始到切换完成期间的所有数据变更都被捕获
  2. 业务无感知: 整个迁移过程中,源库持续提供服务
  3. 可回滚: 切换前源库数据完整,出现问题可快速回滚
  4. 可控切换: 管理员可以选择业务低峰期进行最终切换

五、注意事项

  1. 提前演练: 在测试环境完整走一遍流程
  2. 备份保留: 迁移完成后保留源库备份一段时间
  3. 监控告警: 配置主从延迟监控和告警
  4. 权限同步: 确保新库用户权限与源库一致
  5. 防火墙规则: 确保新库能访问源库的3306端口

六、进阶技巧

使用Percona XtraBackup

对于超大数据库,可以使用XtraBackup替代mysqldump:

# 备份(物理备份,速度更快)
xtrabackup --backup \
  --target-dir=/backup/full \
  --user=root --password=密码

# 会自动记录binlog位置到xtrabackup_binlog_info文件
cat /backup/full/xtrabackup_binlog_info
# 输出: mysql-bin.000015  154

双主模式(高级)

迁移完成后可配置双主模式,实现双向同步,为下次迁移做准备。

七、总结

MySQL不停机迁移的本质是利用binlog的增量复制能力,在全量数据复制的基础上,通过主从同步机制追平增量数据。只要严格按照流程操作,准确记录和配置binlog位置,就能实现真正的零数据丢失迁移。

迁移口诀:

以上就是MySQL不停机迁移的完整指南的详细内容,更多关于MySQL不停机迁移的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:
阅读全文