MyDumper迁移MySQL到Aurora时MEMORY引擎表的处理问题

问题背景

在使用MyDumper工具将MySQL 8.0.35 RDS数据库迁移至Aurora 3.05.2数据库时，遇到了一个关于存储引擎的兼容性问题。具体表现为当源数据库中存在使用MEMORY引擎的表时，迁移过程会被中断并报错"Storage engine MEMORY is disabled (Table creation is disallowed)"。

问题分析

技术细节

Aurora数据库作为MySQL的兼容版本，对某些存储引擎的支持存在限制。测试发现，当直接在Aurora中创建MEMORY引擎表时，虽然会收到警告，但系统会自动将表转换为InnoDB引擎：

CREATE TABLE t3 (i INT) ENGINE = MEMORY;
-- 实际创建的为InnoDB表

然而在使用MyDumper/myloader进行迁移时，工具将Aurora返回的警告信息识别为严重错误，导致整个导入过程中断。这与Aurora实际能够自动转换引擎的行为不符。

根本原因

经过深入分析，发现问题的核心在于：

1. Aurora确实不支持MEMORY引擎，但设计为自动转换为InnoDB
2. 转换过程中Aurora返回了非零错误代码
3. MyDumper/myloader默认将这类错误视为不可恢复的严重错误
4. 这与MySQL客户端直接执行时的宽容处理方式不同

解决方案

临时解决方案

对于急需解决问题的用户，可以尝试以下方法：

1. 在导出前修改源数据库中MEMORY引擎表为InnoDB
2. 手动编辑导出的schema文件，将ENGINE=MEMORY替换为ENGINE=InnoDB
3. 设置SQL_MODE包含NO_ENGINE_SUBSTITUTION参数

长期解决方案

MyDumper开发团队已确认将在下一个版本中增加对此类情况的处理，类似于现有的--success-on-1146参数，专门针对存储引擎转换的警告场景。

最佳实践建议

1. 迁移前检查：使用以下查询识别源库中的MEMORY引擎表：

   SELECT TABLE_SCHEMA, TABLE_NAME 
   FROM INFORMATION_SCHEMA.TABLES 
   WHERE ENGINE = 'MEMORY';
   

2. 测试迁移：先在测试环境执行小规模迁移，验证所有特殊引擎表的处理情况

3. 参数配置：在my.cnf或命令行中添加：

   [myloader_session_variables]
   SQL_MODE='NO_ENGINE_SUBSTITUTION'
   

4. 版本选择：关注MyDumper新版本发布，及时升级以获得更好的兼容性支持

总结

数据库迁移过程中，存储引擎的差异是常见但容易被忽视的问题。MyDumper作为专业的MySQL逻辑备份工具，正在不断完善对各种特殊场景的处理能力。对于Aurora这类云数据库的特殊限制，用户需要提前了解兼容性差异，并采取适当的应对措施。开发团队已积极响应此问题，预计在近期版本中提供更完善的解决方案。