MySQL不停机迁移完全指南
一、为什么需要不停机迁移?
在生产环境中,数据库迁移是一个常见但充满挑战的任务。传统的停机迁移方式会导致业务中断,对于7×24小时运行的互联网服务来说,这种停机时间是不可接受的。不停机迁移方案可以在保证业务连续性的前提下,完成数据库的平滑迁移。
二、核心原理解析
不停机迁移的核心思想是:先全量复制,后增量同步。具体来说:
- 全量备份阶段: 使用mysqldump导出数据,并记录备份时刻的binlog位置
- 数据导入阶段: 将备份数据导入到新数据库
- 增量同步阶段: 通过主从复制机制,从记录的binlog位置开始同步增量数据
- 切换阶段: 数据追平后,切换应用连接到新数据库
这种方案的精妙之处在于:binlog作为增量数据的桥梁,确保了在备份期间和导入期间产生的新数据不会丢失。
三、详细实施步骤
3.1 准备工作
源库配置检查:
bash
# 确认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 |
+---------------+-------+创建复制用户:
sql
-- 在源库创建用于主从复制的专用账号
CREATE USER 'repl_user'@'新库IP' IDENTIFIED BY '强密码';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl_user'@'新库IP';
FLUSH PRIVILEGES;3.2 全量备份并记录binlog位置
这是整个方案的关键步骤!
bash
# 使用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信息:
bash
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 在新库导入数据
bash
# 将备份文件传输到新服务器
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 配置主从复制
在新库(从库)上配置主从关系:
sql
-- 停止从库(如果之前有配置)
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关键状态检查:
sql
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 监控同步进度
bash
# 持续监控延迟情况
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时,准备切换:
- 设置源库为只读(可选,更安全):
sql
-- 在源库执行
SET GLOBAL read_only = ON;
SET GLOBAL super_read_only = ON;- 最终确认数据一致性:
bash
# 对比源库和新库的数据量
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;"- 修改应用配置,指向新库:
yaml
# 应用配置文件示例
database:
host: 新库IP
port: 3306
username: app_user
password: app_password- 重启应用或热更新配置
- 验证业务功能正常
3.7 收尾工作
sql
-- 新库不再需要作为从库时,停止复制
STOP SLAVE;
-- 重置从库配置(可选)
RESET SLAVE ALL;
-- 关闭源库只读模式(如果需要保留源库)
SET GLOBAL read_only = OFF;
SET GLOBAL super_read_only = OFF;四、核心优势
- 零数据丢失: binlog机制保证了从备份开始到切换完成期间的所有数据变更都被捕获
- 业务无感知: 整个迁移过程中,源库持续提供服务
- 可回滚: 切换前源库数据完整,出现问题可快速回滚
- 可控切换: 管理员可以选择业务低峰期进行最终切换
五、注意事项
- 提前演练: 在测试环境完整走一遍流程
- 备份保留: 迁移完成后保留源库备份一段时间
- 监控告警: 配置主从延迟监控和告警
- 权限同步: 确保新库用户权限与源库一致
- 防火墙规则: 确保新库能访问源库的3306端口
六、进阶技巧
使用Percona XtraBackup
对于超大数据库,可以使用XtraBackup替代mysqldump:
bash
# 备份(物理备份,速度更快)
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位置,就能实现真正的零数据丢失迁移。
迁移口诀:
- 全量dump记位置
- source导入打基础
- 主从同步追增量
- 延迟为零再切换