【mysql】MySQL 数据库迁移

【mysql】MySQL 分库分表详解
【mysql】事务隔离级别
【mysql】mysql锁机制
【mysql】什么是死锁？如何避免死锁？
【mysql】InnoDB的聚簇索引和非聚簇索引工作原理
【mysql】centOS7安装mysql详细操作步骤！---通过tar包方式

MySQL 数据库迁移

文章目录

• [MySQL 数据库迁移](#MySQL 数据库迁移)
• • [1. MySQL 数据库迁移总体架构](#1. MySQL 数据库迁移总体架构)
  • [2. 数据库迁移详细流程图](#2. 数据库迁移详细流程图)
  • [3. 迁移方法选择决策图](#3. 迁移方法选择决策图)
  • [4. 逻辑迁移详细流程](#4. 逻辑迁移详细流程)
  • • • [1. 核心工具：`mysqldump`](#1. 核心工具：mysqldump)
      • [2. 操作步骤（离线方式）](#2. 操作步骤（离线方式）)
      • [3. 优缺点](#3. 优缺点)
  • [5. 物理迁移详细流程](#5. 物理迁移详细流程)
  • • • [1. 核心方法：文件拷贝 + 工具](#1. 核心方法：文件拷贝 + 工具)
      • [2. 操作步骤（离线方式）](#2. 操作步骤（离线方式）)
      • [3. 在线物理迁移工具：Percona XtraBackup](#3. 在线物理迁移工具：Percona XtraBackup)
      • [4. 优缺点](#4. 优缺点)
  • [6. 在线迁移（主从复制）流程](#6. 在线迁移（主从复制）流程)
  • [7. 迁移验证与测试流程](#7. 迁移验证与测试流程)
  • [8. 切换与回滚方案](#8. 切换与回滚方案)
  • 总结

迁移思路通常包括以下步骤：

1. 环境评估：了解源和目标数据库的版本、大小、字符集、引擎等。
2. 迁移方案选择：根据停机时间要求、数据一致性要求等选择逻辑迁移或物理迁移。
3. 预迁移检查：检查数据库一致性、备份源数据库、确保目标环境准备就绪。
4. 执行迁移：使用选定的工具和方法进行迁移。
5. 数据验证：迁移后检查数据的完整性和一致性。
6. 应用切换：将应用连接到新的数据库，可能涉及停机或切换。
7. 后期维护：监控目标数据库性能，确保稳定运行。

1. MySQL 数据库迁移总体架构

MySQL数据库迁移项目 迁移规划阶段 迁移实施阶段 迁移验证阶段 切换上线阶段 需求分析 环境评估 方案设计 风险评估 数据备份 结构迁移 数据迁移 应用适配 数据校验 性能测试 功能测试 兼容性测试 切换计划 回滚方案 正式切换 监控运维

2. 数据库迁移详细流程图

迁移后优化 是 否 性能优化 运行监控 清理资源 开始迁移 预迁移检查 源库分析 目标环境准备 网络连通性 权限验证 制定迁移方案 选择迁移方法 逻辑迁移 物理迁移 在线迁移 离线迁移 全量备份 结构迁移 数据迁移 数据同步 数据验证 验证通过? 应用切换 问题修复 迁移完成

3. 迁移方法选择决策图

小数据量 < 100GB 大数据量 > 100GB 允许停机 零停机 同版本 跨版本 选择迁移方法 数据量大小? 逻辑迁移 停机时间要求? 物理迁移 数据库版本? 复制+切换 工具迁移 mysqldump
mysqlpump 文件级备份
XtraBackup 主从复制
MySQL Replication MySQL Shell
第三方工具 适用场景
版本升级
跨平台迁移 适用场景
大数据量
同平台迁移 适用场景
高可用
零停机迁移 适用场景
复杂迁移
云迁移

4. 逻辑迁移详细流程

• 离线逻辑迁移 ：用 mysqldump 导出导入，期间源库不可写。
• 在线逻辑迁移 ：使用第三方工具如 mysqldumper、阿里云DTS等，实现不停机的逻辑迁移。

1. 核心工具：mysqldump

这是最经典、最常用的逻辑迁移工具，它生成的是SQL文件。

适用场景：

• 数据量不大（通常建议在几十GB以内）。
• 需要跨版本迁移（如MySQL 5.7 -> 8.0）。
• 需要跨引擎迁移（如MyISAM -> InnoDB）。
• 只需要迁移部分表或数据。

2. 操作步骤（离线方式）

a. 在源数据库导出

# 导出所有数据库（结构和数据）
mysqldump -h [源主机] -u [用户名] -p[密码] --all-databases --single-transaction --master-data=2 --routines --triggers --events > full_backup.sql

# 导出单个数据库
mysqldump -h [源主机] -u [用户名] -p[密码] --databases [数据库名] --single-transaction > db_backup.sql

# 导出单张表
mysqldump -h [源主机] -u [用户名] -p[密码] [数据库名] [表名] > table_backup.sql

参数解释：

• --single-transaction： 开启一个事务来确保数据一致性，适用于InnoDB引擎。（关键参数）
• --master-data=2： 在输出文件中记录当前源的二进制日志位置，用于后续搭建主从复制。
• --routines： 导出存储过程和函数。
• --triggers： 导出触发器。
• --events： 导出事件。

b. 将备份文件传输到目标服务器

scp full_backup.sql user@target_server:/path/to/backup/

c. 在目标数据库导入

mysql -h [目标主机] -u [用户名] -p[密码] < full_backup.sql

3. 优缺点

• 优点 ：
  • 灵活，可以选择性迁移。
  • 格式通用，兼容性好。
  • 备份文件可读。
• 缺点 ：
  • 数据量大时，导出和导入非常耗时。
  • 导入过程需要重建索引，性能开销大。
  • 在迁移过程中，源库如有新数据写入，需要停机才能保证一致性。

导入阶段 导出阶段 mysql < schema.sql SQL结构文件 mysql < data.sql SQL数据文件 分批导入优化 mysqldump -d 导出结构 mysqldump -t 导出数据 分批导出大表 源数据库 目标数据库 验证数据

5. 物理迁移详细流程

1. 核心方法：文件拷贝 + 工具

直接拷贝MySQL的数据目录（datadir），通常需要借助文件系统工具（如 rsync, tar）或专业备份工具。

适用场景：

• 数据量非常大（几百GB以上）。
• 追求最快的迁移速度。
• 源和目标环境高度相似（MySQL版本、配置等）。

2. 操作步骤（离线方式）

a. 关闭源数据库，确保数据一致

# 在源服务器上
systemctl stop mysql
# 或 mysqladmin -u root -p shutdown

b. 打包并传输数据文件

# 在源服务器上，假设 datadir 是 /var/lib/mysql
tar -czf mysql_data.tar.gz /var/lib/mysql/

# 传输到目标服务器
scp mysql_data.tar.gz user@target_server:/path/to/

c. 在目标服务器准备环境

• 安装相同版本（或兼容版本）的MySQL。
• 停止目标MySQL服务。
• 清空 目标服务器的 datadir 目录。
• 解压数据文件到目标 datadir。
• 重要 ：确保文件权限和属主正确（通常是 mysql:mysql）。

# 在目标服务器上
systemctl stop mysql
rm -rf /var/lib/mysql/*
tar -xzf /path/to/mysql_data.tar.gz -C /var/lib/mysql/ --strip-components=1 # 注意strip-components
chown -R mysql:mysql /var/lib/mysql

d. 启动目标数据库

systemctl start mysql

3. 在线物理迁移工具：Percona XtraBackup

这是一个开源的热备份工具，可以在不锁表的情况下进行物理备份，是实现在线物理迁移的利器。

大致步骤：

1. 在源库备份：

   xtrabackup --backup --host=[源主机] --user=[用户] --password=[密码] --target-dir=/path/to/backup/

2. 准备备份（使备份文件处于一致状态）：

   xtrabackup --prepare --target-dir=/path/to/backup/

3. 传输备份文件到目标服务器。

4. 在目标库恢复：

   # 停止目标MySQL
   systemctl stop mysql
   # 清空datadir
   rm -rf /var/lib/mysql/*
   # 恢复
   xtrabackup --copy-back --target-dir=/path/to/backup/
   # 修改权限
   chown -R mysql:mysql /var/lib/mysql
   # 启动MySQL
   systemctl start mysql

4. 优缺点

• 优点 ：
  • 速度快，尤其对于大数据库。
  • 恢复过程简单，无需重建索引。
• 缺点 ：
  • 不灵活，不能选择部分数据。
  • 对源和目标环境的一致性要求高。
  • 离线方式需要停业务。

备份工具选择 XtraBackup 文件级备份 文件系统快照 冷备份 源数据库 停止写入 数据文件 日志文件 配置文件 传输文件 目标服务器 恢复文件 权限设置 启动服务 验证服务

6. 在线迁移（主从复制）流程

在线迁移的核心思想是先全量同步，再实时同步增量数据，最后在业务低峰期进行切换。

常用工具：

1. MySQL主从复制 ：
   • 将目标库配置为源库的从库，让它们自动同步。
   • 同步追上后，暂停应用，将读写流量切换到目标库（提升为主库）。
   • 这是最经典、最可靠的MySQL在线迁移方案。
2. 第三方数据同步服务 ：
   • 云服务商：阿里云DTS、腾讯云DTS、AWS DMS等。它们提供了图形化界面，简化了流程。
   • 开源工具 ：gh-ost（用于在线DDL，也可用于迁移）、canal、Maxwell（基于解析binlog）。

基于主从复制的在线迁移步骤：

1. 全量备份 ：使用 mysqldump（带 --master-data）或 XtraBackup 对源库做一次全量备份，并记录当前的binlog位置。
2. 恢复至目标库：将全量备份恢复到目标库。
3. 配置主从 ：在目标库上执行 CHANGE MASTER TO 命令，指向源库和全量备份时的binlog位置。
4. 启动复制 ：在目标库执行 START SLAVE，开始追增量数据。
5. 监控同步 ：使用 SHOW SLAVE STATUS 监控 Seconds_Behind_Master，直到为0，表示同步完成。
6. 业务切换 ：
   • 停止应用程序对源库的写入。
   • 在目标库再次检查延迟，确保为0。
   • 在应用程序配置中，将数据库连接地址修改为目标库地址。
   • 开启应用程序服务。
   • 此时，目标库已成为新的主库。

应用 源数据库(主) 目标数据库(从) 初始阶段：搭建复制 全量备份 恢复数据 开启二进制日志复制 运行阶段：数据同步 读写操作 实时复制数据变更 应用二进制日志 切换阶段：主从切换 停止写入 等待数据完全同步 提升为主库 切换到新主库 应用 源数据库(主) 目标数据库(从)

7. 迁移验证与测试流程

通过 不通过 迁移验证 数据完整性检查 数据一致性检查 性能基准测试 功能回归测试 记录数对比 关键数据抽样 校验和验证 业务逻辑验证 关联关系检查 约束完整性 查询性能 并发处理 资源使用率 应用功能测试 接口测试 报表验证 生成验证报告 验证结果 准备切换 问题分析与修复

8. 切换与回滚方案

正式切换流程 是 否 最终数据同步 停止源库写入 应用指向新库 验证新环境 验证成功? 切换完成 执行回滚 切换准备 制定切换计划 准备回滚方案 数据回滚 应用回滚 配置回滚 备份当前状态 快速恢复方案 应用版本管理 连接串切换 配置文件备份 快速回滚脚本 恢复原状态 分析失败原因 重新规划迁移

总结

迁移方式	适用场景	优点	缺点
离线逻辑迁移 (mysqldump)	小数据量，跨版本/引擎，选择性迁移	灵活，通用	速度慢，停机时间长
在线逻辑迁移 (DTS/mydumper)	中小数据量，要求业务不停机	几乎零停机，对业务影响小	配置复杂，可能比物理方式慢
离线物理迁移 (文件拷贝)	超大数据量，同构环境，追求速度	速度极快	需要停机，环境要求严格
在线物理迁移 (XtraBackup)	超大数据量且要求在线	速度快，可热备份	配置比逻辑迁移复杂
在线主从复制	生产环境最推荐的标准方案	可靠，停机时间极短，可读性验证	配置和管理有一定复杂度

如何选择？

1. 数据量：< 50GB，优先考虑逻辑迁移；> 100GB，优先考虑物理迁移。
2. 停机窗口：允许停机数小时？用离线方式。要求几乎零中断？必须用在线方式（主从复制或第三方工具）。
3. 环境一致性：源和目标MySQL版本、配置、路径是否一致？一致则物理迁移更方便。
4. 技能水平：主从复制需要一定的MySQL知识，而云厂商的DTS等服务大大降低了操作难度。

通用建议 ：无论选择哪种方案，一定要在测试环境进行完整的演练，记录准确的耗时，并制定详细的回滚计划。