AWS RDS MySQL 5.7 MyISAM迁移、备份与引擎转换技术咨询

我来帮你梳理一套实操性强的完整流程，涵盖迁移、引擎转换和自动备份配置，都是实际运维中验证过的方案：

一、迁移前准备工作 #

• 先摸清家底：在源RDS上执行这条SQL，列出所有MyISAM表，方便后续核对：

  SELECT table_name FROM INFORMATION_SCHEMA.TABLES 
  WHERE engine='MyISAM' AND table_schema='你的数据库名称';
  

• 协调停机窗口：因为MyISAM不支持事务级备份，迁移和转换过程中需要短暂停止业务写入，提前和业务团队沟通好时间点。
• 配置目标RDS：确保目标实例在自定义VPC内，网络能连通源RDS（同VPC或VPC peering，安全组开放3306端口），且实例配置（CPU、内存、存储）不低于源实例，避免后续性能瓶颈。

二、迁移数据到目标RDS #

这里提供两种方案，按需选择：

方案1：mysqldump全量迁移（适合小型数据库） #

• 停止源RDS写入：先暂停业务对源库的写操作，保证数据一致性。
• 导出源库数据：用EC2跳板机或者本地机器执行导出命令：

  mysqldump -h 源RDS端点 -u 用户名 -p \
  --databases 你的数据库名 --routines --triggers > my_db_backup.sql
  

  注意：MyISAM不支持--single-transaction，所以必须停写后再导出，否则会出现数据不一致。

• 导入到目标RDS：把备份文件传到能访问目标RDS的环境，执行导入：

  mysql -h 目标RDS端点 -u 用户名 -p < my_db_backup.sql
  

• 验证数据：对比源和目标库的表行数、关键数据，确保迁移完整。

方案2：AWS DMS迁移（低停机，适合大型数据库） #

• 创建DMS复制实例：放在能连通源和目标RDS的VPC中，配置足够的资源保证迁移速度。
• 配置端点：分别创建源端点（指向源RDS）和目标端点（指向自定义VPC的目标RDS）。
• 创建迁移任务：选择「全量迁移+持续复制（CDC）」，先同步全量数据，再实时同步增量变更，最后切换业务到目标实例，大幅缩短停机时间。
• 验证一致性：迁移完成后，用DMS的数据校验功能或者自行核对关键表数据。

三、将MyISAM表转换为InnoDB #

• 停止目标RDS写入：切换业务到目标实例后，暂停写操作，避免转换过程中数据变更。
• 批量转换引擎：先生成转换脚本，再批量执行：

  -- 生成转换SQL
  SELECT CONCAT('ALTER TABLE ', table_name, ' ENGINE=InnoDB;') 
  FROM INFORMATION_SCHEMA.TABLES 
  WHERE engine='MyISAM' AND table_schema='你的数据库名';
  

  把查询结果复制出来，批量执行这些ALTER TABLE命令。
• 验证转换结果：执行这条SQL确认所有表都已转为InnoDB：

  SELECT table_name, engine FROM INFORMATION_SCHEMA.TABLES 
  WHERE table_schema='你的数据库名';
  

• 优化InnoDB配置：调整目标RDS的参数组，比如设置innodb_buffer_pool_size为实例内存的50%-70%，innodb_log_file_size根据业务吞吐量调整，提升InnoDB性能。

四、配置自动备份（转InnoDB后无需特殊操作） #

• 转成InnoDB后，RDS的自动备份功能可以正常工作了，不需要再执行停止活动的特殊流程：
  • 登录RDS控制台，进入目标实例的「备份」标签，确认自动备份已开启，设置合适的备份保留期（比如7-30天）。
  • 手动触发一次快照测试：创建快照后，尝试恢复一个测试实例，检查数据是否完整，确保备份机制正常。

关键注意事项 #

• 转换引擎前一定要给目标RDS创建手动快照，万一转换出错可以快速回滚。
• MyISAM转InnoDB后，锁机制从表锁变为行锁，性能会提升，但要注意应用中的长事务或大查询，避免引发锁等待问题。
• 目标RDS建议选用GP3存储类型，相比GP2有更好的IO性能，更适配InnoDB的随机读写特性。

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