AWS DMS迁移timestamp列时区异常：初始转UTC，恢复后更新行正常

我来帮你拆解这个问题，这其实是AWS DMS在全量迁移和**CDC（持续变更捕获）**两个阶段对timestamp类型的处理逻辑差异导致的，具体原因和解决办法如下：

问题原因分析 #

1. 全量迁移阶段的时区转换逻辑 #

AWS DMS任务默认使用UTC作为全局时区。在全量迁移时，它会把源库（Asia/Calcutta时区）中timestamp列的本地显示时间转换为UTC时间，然后直接写入目标库的timestamp列。哪怕目标库的参数组已经设置为Asia/Calcutta，DMS不会自动把UTC时间转换回目标时区——它只是把UTC值作为timestamp的存储值写入。这就导致目标库查询时，这些值会显示为UTC时间（而非预期的Asia/Calcutta本地时间）。

2. CDC阶段的正确处理逻辑 #

当你停止并恢复DMS任务后，增量变更会通过CDC模式处理。DMS会读取源库的变更日志（比如MySQL的binlog），这些日志里记录的是timestamp列的实际UTC存储值（不是本地显示时间）。DMS会把这个值直接写入目标库，目标库会根据自身的Asia/Calcutta时区设置，自动在查询时转换为本地时间，所以更新后的行（行1）显示正常。而未被更新的行（行2）还保留着全量迁移时写入的UTC值，因此显示异常。

解决办法 #

1. 修改DMS任务的时区参数 #

这是最直接的解决方案：

• 创建或修改DMS任务时，找到任务设置中的TimeZone参数，将其设置为Asia/Calcutta（和源、目标库时区一致）。
• 这个参数会告诉DMS在全量迁移时使用指定时区处理时间类型，避免不必要的UTC转换。

2. 重新执行全量迁移（可选） #

如果已经完成初始全量迁移，需要：

• 停止当前任务，然后重置任务的全量迁移部分（或创建一个新的“迁移现有数据并复制持续变更”任务），确保新任务使用正确的TimeZone参数。
• 这样能让所有历史数据的timestamp值都同步为正确的Asia/Calcutta本地时间。

3. 验证目标库的时区设置 #

确保目标库的全局和会话时区都正确设置为Asia/Calcutta：

• 以MySQL为例，执行SELECT @@global.time_zone, @@session.time_zone;检查时区配置。
• 如果会话时区不是Asia/Calcutta，可以通过SET time_zone = 'Asia/Calcutta';临时调整，或修改数据库参数组永久生效。

4. 使用DMS转换规则（进阶） #

如果无法修改任务时区，可通过DMS的转换规则显式处理timestamp列：

• 创建一个转换规则，针对目标表的timestamp列，设置ConvertTimezone操作，将源时区Asia/Calcutta转换为目标时区Asia/Calcutta，强制跳过UTC转换步骤。

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