当前位置：首页 > news >正文

MySQL不停机迁移完全指南

news 2025/11/13 18:52:15

MySQL不停机迁移完全指南

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

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

二、核心原理解析

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

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

这种方案的精妙之处在于: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;

记住这两个关键信息:

MASTER_LOG_FILE: binlog文件名(如mysql-bin.000015)
MASTER_LOG_POS: binlog位置(如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 TOMASTER_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 eventSlave_IO_Running: Yes  -- 必须是YesSlave_SQL_Running: Yes  -- 必须是YesSeconds_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时,准备切换:

设置源库为只读(可选,更安全):

-- 在源库执行
SET GLOBAL read_only = ON;
SET GLOBAL super_read_only = ON;

最终确认数据一致性:

# 对比源库和新库的数据量
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;"

修改应用配置,指向新库:

# 应用配置文件示例
database:host: 新库IPport: 3306username: app_userpassword: app_password

重启应用或热更新配置
验证业务功能正常

3.7 收尾工作

-- 新库不再需要作为从库时,停止复制
STOP SLAVE;-- 重置从库配置(可选)
RESET SLAVE ALL;-- 关闭源库只读模式(如果需要保留源库)
SET GLOBAL read_only = OFF;
SET GLOBAL super_read_only = OFF;

四、核心优势

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

五、注意事项

提前演练: 在测试环境完整走一遍流程
备份保留: 迁移完成后保留源库备份一段时间
监控告警: 配置主从延迟监控和告警
权限同步: 确保新库用户权限与源库一致
防火墙规则: 确保新库能访问源库的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