AWS Glue任务执行成功但DynamoDB数据未写入MySQL的排查请求

• 验证Glue任务的实际数据流转
  去Glue任务的CloudWatch日志里搜ReadRecords、WriteRecords关键字，确认有没有真读到DynamoDB的20条数据，以及写入MySQL的记录数是不是0。另外看Glue作业详情里的Metrics，重点看Records Read、Records Written这俩指标，有时候任务显示“成功”只是流程走完，根本没处理数据。

• 深挖MySQL OOM的根源（升级规格还没解决）

  • 检查MySQL的my.cnf配置，重点盯innodb_buffer_pool_size、sort_buffer_size这些内存参数。升级实例后默认配置可能没跟上，比如内存加了但buffer pool还是老的小值，导致内存分配乱套。
  • 执行SHOW ENGINE INNODB STATUS;命令，看InnoDB的内存使用细节，有没有异常占用。
  • 查Glue的写入批次设置：哪怕只有20条数据，如果Glue的batchSize设得不合理，或者数据类型转换时临时占了太多内存，也可能触发OOM。

• 核对Glue Data Catalog与实际表的结构一致性
  对比DynamoDB表和Glue Catalog里的表结构，确认title列类型匹配（比如DynamoDB是字符串类型，Catalog里也是string）。再对比MySQL表和Catalog的结构，确保title列的长度（比如varchar的长度）能装下数据，避免类型不兼容导致写入失败但Glue没报错。

• 检查Glue作业的写入逻辑

  • 如果是自定义Spark脚本，看看写入MySQL的代码有没有被注释，或者有没有条件判断把数据过滤没了。
  • 如果是可视化ETL，检查数据流转节点：写入前是不是加了过滤操作把所有数据都筛掉了？写入模式是不是设错了（比如overwrite但没数据，或者append连接有问题）。

• 排查MySQL的权限与连接问题

  • 确认Glue用的IAM角色有足够权限写RDS MySQL，有时候权限不足不会触发Glue报错，但数据就是写不进去。
  • 检查MySQL用户权限：Glue连接用的MySQL账号有没有目标表的INSERT权限？有没有SELECT权限（有些写入操作需要读表结构）。
  • 开启MySQL的general log（设general_log=1），看有没有Glue发起的连接和写入请求，以及请求内容里有没有隐藏的错误。

• 手动测试写入MySQL
  从DynamoDB导出1-2条数据，用MySQL客户端手动插目标表。如果手动也失败，说明是MySQL表本身的问题（比如约束冲突、字段长度不够）；如果手动成功，那问题肯定在Glue的配置或写入逻辑上。

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