AWS DMS - CDC - 唯一约束错误

0

【以下的问题经过翻译处理】 如何解决AWS DMS CDC模式下的"ORA-00001: unique constraint"错误?

源-本地-Oracle || 目标-AWS RDS-Oracle

我使用带有SCN的Datapump导出源数据库,导入到目标数据库并以相同的SCN开始迁移任务,但是我遇到了"ORA-00001: unique constraint"错误,因此迁移任务从"批量应用"改为"一个一个执行"。

我在拥有超过1亿条记录的表中遇到了上述错误。我该如何摆脱这个错误?我需要在进行导出操作之前做出任何更改吗?

profile picture
专家
已提问 8 个月前73 查看次数
1 回答
0

【以下的回答经过翻译处理】 您可以将表划分为多个任务以提高 CDC 性能。您可以查看目标数据库架构中的“awsdms_apply_exceptions”以了解有关违规的更多信息。增加日志记录将为有关违规发生原因给您提供的更多信息(应用提交之前批处理事务中的重复数据与键上的实际违规)。

https://aws.amazon.com/premiumsupport/knowledge-center/dms-enable-debug-logging/

此外,您还可以启用 BatchApplyEnabled 和禁用 (BatchApplyPreserveTransaction),请参考以下链接了解更多信息:

https://docs.aws.amazon.com/zh_cn/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.html

AWS DMS 在变更数据捕获 (CDC) 阶段使用以下方法复制数据:

Transactional apply
Batch apply

默认情况下,AWS DMS CDC 进程是单线程的(事务应用)。这与所有其他联机事务处理 (OLTP) 数据库引擎用于 SQL 复制的方法相同。 DMS CDC 复制依赖于源数据库事务日志。在持续复制阶段,DMS 使用事务性应用方法应用更改,如下所示:

DMS 将事务日志中的更改从源读取到复制数据库实例内存中。
DMS 转换更改,然后将它们传递给排序器组件。
排序器组件按提交顺序对事务进行排序,然后按顺序将它们转发到目标。

如果源数据库上的更改率很高,则此过程可能需要一些时间。当 DMS 从源数据库接收到大量传入工作负载时,您可能会观察到 CDC 目标延迟指标出现峰值。

DMS 使用单线程复制方法来处理 CDC 更改。 DMS 提供任务级别设置 BatchApplyEnabled 以使用批处理快速处理目标上的更改。如果您在源数据库上有高工作负载,并且任务具有目标较高的 CDC 延迟,则 BatchApplyEnabled 很有用。默认情况下,DMS 禁用 BatchApplySetting。您可以使用 AWS 命令​​行界面 (AWS CLI) 启用此功能。

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.html

如果您使用 BatchApplyEnabled 运行任务,DMS 将按以下方式处理更改:

DMS 从源数据库事务日志中批量收集更改。
DMS 创建一个名为净更改表,其中包含批处理中的所有更改。
该表驻留在复制数据库实例的内存中,并传递给目标数据库实例。
DMS 应用净变化算法,将净变化表中的所有变化更新到实际目标表中。

例如,如果您使用 BatchApplyEnabled 运行 DMS 任务,并且您有一个新的行插入、对该行的十次更新以及对该行的一次删除,那么 DMS 会扣除所有这些事务并且不会将它们结转。它这样做是因为该行最终被删除并且不再存在。此过程减少了应用于目标的实际事务数量。

BatchApplyEnabled 在特定任务的批处理中在表的行级别应用净更改算法。因此,如果源数据库频繁更改(更新、删除和插入)或这些工作负载的组合在同一行上,则您可以从 BatchApplyEnabled 获得最佳使用方法。这最大限度地减少了要应用于目标的更改。如果收集到的批次在变化上是唯一的(更新/删除/插入不同行记录的变化),那么净更改表算法过程无法过滤任何事件。因此,所有批处理事件都会以批处理模式应用于目标。表必须具有主键或唯一键才能进行批量应用。

DMS 还为应用更改调优提供了 BatchApplyPreserveTransaction 设置。如果您启用 BatchApplySetting,则 BatchApplyPreserveTransaction 默认打开。如果将其设置为 true,则会保留事务完整性。批处理保证包含来自源的事务中的所有更改。此设置仅适用于 Oracle 目标端点。

当 BatchApplyPreserveTransaction 设置为真时,DMS 在复制数据库实例的内存中捕获整个长时间运行的事务。它根据任务设置 MemoryLimitTotal 和 MemoryKeepTime 执行此操作,并根据需要进行交换,然后再将更改发送到净更改表。当 BatchApplyPreserveTransaction 设置为 false 时,来自单个事务的更改可以跨越多个批次。这可能会在部分应用时导致数据丢失,例如,由于目标数据库不可用。

[+] https://aws.amazon.com/blogs/database/debugging-your-aws-dms-migrations-what-to-do-when-things-go-wrong-part-2/

[+] https://aws.amazon.com/blogs/database/debugging-your-aws-dms-migrations-what-to-do-when-things-go-wrong-part-3/

以下情况可以使用批量申请:

该任务具有从源捕获的大量事务,这会导致目标延迟。
该任务具有来自源的工作负载,它是对相同行的插入、更新和删除的组合。
无需在目标上保持严格的参照完整性(禁用 FK)。

当 BatchApplyEnabled 设置为 true 时,如果目标表具有唯一约束,则 AWS DMS 会生成一条错误消息。

因此,我建议启用 Batch apply to 'true' 并将 BatchApplyTimeoutMin 增加到 ~300 秒(5 分钟),将 BatchApplyTimeoutMax 增加到 600 秒(10 分钟)并增加 BatchApplyMemoryLimit(取决于复制实例上当前的可用内存)。

这意味着 DMS 只会每 10 分钟或在复制实例上捕获 BatchApplyMemoryLimit 事务后才发送一个批次到目标。通过允许进行更大、频率更低的提交,这应该对目标延迟产生积极影响。要改变这个设置,停止任务,修改设置,保存更改并恢复任务(可以先在测试环境中测试以监控变化,以防您需要进一步增加 BatchApplyMemoryLimit)。

只有在 BatchApplyTimeoutMin 中的时间量过去后,DMS 才会评估 BatchApplyTimeoutMax 和 BatchApplyMemoryLimit。一旦达到 BatchApplyTimeoutMax 或 BatchApplyMemoryLimit 的值之一,批处理将被发送到目标。因此,换句话说,一旦 BatchApplyTimeoutMin 过去,BatchApplyTimeoutMax 和 BatchApplyMemoryLimit 之间的先到者将触发 DMS 将批次发送到目标。

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.html

profile picture
专家
已回答 8 个月前

您未登录。 登录 发布回答。

一个好的回答可以清楚地解答问题和提供建设性反馈,并能促进提问者的职业发展。

回答问题的准则