相同配置Amazon RDS间单MySQL数据库迁移高效恢复方案咨询

下面是经过生产验证的可落地方案，按实施复杂度和提速效果排序：

一、优化现有逻辑备份恢复流程（无需额外工具，可快速验证） #

恢复速度慢90%以上的原因是默认RDS参数配置为了数据安全做了保守设置，恢复期间临时调整以下配置即可大幅提速：

• 调整RDS B的参数组配置（恢复完成后务必改回原值）：
  • 将innodb_flush_log_at_trx_commit设为2，sync_binlog设为0，可降低刷盘频率，提升写入速度3倍以上
  • 将innodb_buffer_pool_size调整为实例内存的70%（32G规格可设为22G），减少恢复过程中的磁盘IO次数
  • 临时关闭慢查询日志、通用查询日志，避免不必要的磁盘写入
• 调整备份导出和恢复的参数：
  • 导出时给mysqldump增加--add-locks --disable-keys --quick --single-transaction参数，减少导出时的锁开销，生成的备份文件更适合快速恢复
  • 恢复前在SQL文件开头添加以下语句：

    SET AUTOCOMMIT=0;
    SET UNIQUE_CHECKS=0;
    SET FOREIGN_KEY_CHECKS=0;
    

    恢复完成后执行COMMIT;再把上述三个参数改回原值即可
• 拆分导出恢复流程：先导出导入表结构和数据，再单独导出导入存储过程、触发器、函数，避免恢复过程中频繁切换执行上下文

二、使用多线程逻辑备份工具（提速3-5倍，实施成本低） #

mysqldump是单线程执行，面对大库效率极低，替换为mydumper/myloader多线程备份恢复工具即可大幅提升效率：

• 你当前的8核规格实例可以开4-6个线程执行备份恢复，95GB数据的恢复时间可以压缩到2小时以内
• 支持单库、单表级别的导出导入，完全匹配你只迁移单个业务库的需求
• 支持断点续传，避免网络波动导致恢复中断需要重来的问题

三、使用AWS原生托管迁移方案（适合需要低停机的场景） #

如果业务允许的停机窗口很短，可以选择AWS官方托管的迁移方案：

• 用AWS DMS（数据库迁移服务）做全量+增量同步：先后台执行全量数据同步，同步完成后持续追增量数据，业务停机切换的窗口可以控制在分钟级
• 物理备份导入：在同可用区创建一台临时EC2，用Percona XtraBackup工具导出RDS A对应业务库的物理备份，上传到S3后直接导入到RDS B，物理备份的恢复速度比逻辑备份快5倍以上，95GB数据1小时以内即可完成恢复

注意事项 #

1. 所有临时调整的参数在迁移完成、数据校验通过后必须改回生产默认配置，避免出现数据丢失风险
2. 迁移完成后建议用pt-table-checksum工具做数据一致性校验，确认两边数据完全一致
3. 如果你的RDS实例使用的是GP3存储，现在官方已经支持存储缩容，可以先确认是否满足缩容条件，不需要迁移即可降低存储成本

内容的提问来源于stack exchange，提问作者Gutierrez