使用DMS迁移多Schema MySQL至RDS Aurora MySQL时内存耗尽故障

核心原因 #

数千个独立Schema的场景下，DMS默认会全量扫描并缓存所有Schema的元数据（表结构、索引等），同时并发迁移大量表会导致内存中累积未释放的任务数据和缓存对象，最终触发内存耗尽报错。

分步解决方案 #

1. 拆分迁移任务，缩小单次迁移范围 #

不要一次性同步所有Schema，将数千个Schema分成多个批次（比如每50-100个Schema为一组），创建独立的DMS迁移任务分别处理。在任务的Table mappings配置中，使用include规则明确指定当前批次的Schema，避免DMS扫描全量Schema元数据：

{
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "1",
      "object-locator": {
        "schema-name": "schema_*_batch1",
        "table-name": "%"
      },
      "rule-action": "include"
    }
  ]
}

2. 调整DMS任务内存相关参数 #

• 降低并发加载数：修改max_parallel_loads参数，从默认的8调整为2-4，减少同时迁移的表数量，降低内存占用峰值。
• 启用按表提交事务：开启commit_transaction_per_table参数，让DMS在单个表迁移完成后立即提交事务并释放该表的内存缓存，避免累积占用。
• 减小批量迁移尺寸：将batch_size从默认的1000调至200-500，减少单次加载到内存的数据量。

3. 优化复制实例配置 #

如果当前使用的是低内存规格的复制实例（如t3系列），临时升级到内存优化型实例（如r5.large或更大），但这需配合上述参数调整才能从根本解决问题，避免单纯升级后仍出现内存耗尽。

4. 禁用非必要功能 #

• 若仅需全量迁移无需CDC（持续数据同步），在任务配置中关闭CDC选项，减少日志解析和缓存的内存开销。
• 关闭validate_only模式（若开启），避免额外的元数据校验消耗内存。

进阶排查与优化 #

• 监控内存明细指标：在CloudWatch中重点关注TaskMemoryUsage、TableCacheSize、PendingRecords指标，定位是元数据缓存还是未提交的迁移数据导致内存攀升。
• 预导入Schema结构：提前将所有Schema的表结构手动导出并导入到Aurora，让DMS仅迁移数据，减少DMS在元数据解析和结构创建上的内存消耗。

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