亚马逊 TimeHub 团队如何为其数据复制框架设计恢复和验证框架：第 4 部分

在 Amazon TimeHub 团队如何处理由 Oracle RESETLOGS 导致的亚马逊云科技 DMS CDC 任务中断：第 3 部分中，我们讨论了在 Oracle 重置日志场景中如何使用 Amazon Database Migration Service (亚马逊云科技 DMS) 和 Amazon Glue 构建和测试数据复制恢复框架。我们介绍了任务恢复过程中的步骤以及如何确认恢复后没有数据差异。借助亚马逊云科技 DMS，您可以使用数据验证来确保您的数据准确地从源迁移到目标。如果您启用任务验证，亚马逊云科技 DMS 将在对表执行满负荷后立即开始比较源数据和目标数据。

在这篇文章中，我们描述了我们在亚马逊云科技 DMS 验证任务之上构建的自定义框架，该框架旨在维护数据完整性，这是源数据库和目标数据库之间持续复制的一部分。

解决方案概述

在故障恢复场景中，我们需要一个标准的操作程序来从此类故障中恢复并继续保持数据完整性。

在以下各节中，我们将介绍亚马逊云科技 DMS 中可用于数据验证的功能及其局限性。然后，我们将分享我们如何开发自定义数据验证框架来解决局限性，从而满足亚马逊 TimeHub 的业务需求。在本用例中，我们使用兼容亚马逊 Aurora PostgreSQL 的版本作为目标数据库。

亚马逊云科技 DMS 数据验证框架

在复制过程中，亚马逊云科技 DMS 提供数据验证。为实现此目的，验证任务首先将所有数据读入复制实例，然后对源和目标之间的每条记录执行验证。然后，亚马逊云科技 DMS 读取日志并根据日志验证即将发生的更改。亚马逊云科技 DMS 在其验证任务中提供了两个选项：

使用@@ 持续复制进行验证 -此选项使用复制任务，该任务还会验证来自源的数据
仅限验证的任务 — 在此模式下，我们创建独立的验证任务，以独立于复制任务来验证数据

我们希望使验证任务独立于复制任务，这样即使在复制任务失败后验证任务仍能运行并报告数据差异。这样做是为了保持两种不同功能之间的隔离。我们已经对复制任务的性能进行了基准测试，这些任务符合我们的业务 SLA。由于我们环境中的数据更改率很高，我们希望确保持续复制时性能稳定，因此我们决定仅使用独立的验证任务。

仅限验证的任务工作流程

下图说明了仅限验证的任务的工作流程。

仅限验证的亚马逊云科技 DMS CDC 任务首先验证完整数据，并将这段时间内即将发生的更改缓存到亚马逊云科技 DMS 复制实例缓存中。验证一次性数据后，它会继续根据目标中存在的数据验证传入的数据。为了允许目标出现复制延迟，有一个以秒为单位的可配置阈值，亚马逊云科技 DMS 在将记录记录记录为验证错误之前会等待该阈值。在撰写本文时，阈值设置为 15 分钟（900 秒）。它会多次验证数据，直到达到阈值等待时间，然后再将其记录为错误。

下表包含亚马逊云科技 DMS 记录的验证错误示例数据。

任务名称	表所有者	表名	FAILURE_TIME	密钥类型	钥匙	失败类型	详情
验证任务_1	<table_owner>	表 1	<failure_1_Timestamp>	行	{ “密钥”：[“4905298532”]}	RECORD_DIFF	<null>[[{'col_1': '3767801528'}, {'col_1': '}<null>], [{' col_2 ': '2023-08-25 20:42:00'}, {'col_2': '2023-08-25 20:27:00 '}], [{' col_3 ':' 900 '}, {' col_3 ':' 0 '}], [{' col_4 ':' out '}, {' col_4 ':' missedOut '}], [{' col_5 ':' 0 '}, {' col_5 ':' 1 '}, [{' col_6 ': '2023-08-26 03:27:53'}, {'col_6': '2023-08-26 03:27:08 '}], [{' col_7 ':' 1 '}, {' col_7 ':'}],]
验证任务_2	<table_owner>	表 2	<failure_2_Timestamp>	行	{ “密钥”：[“4905285340”]}	MISSING_SOURCE

亚马逊云科技 DMS 验证的局限性

亚马逊云科技 DMS 数据验证有以下限制：

失败限制 — 亚马逊云科技 DMS 对在暂停任务验证之前可能失败的最大记录数有限制（数据验证任务设置）。一旦达到应用错误的阈值（错误处理任务设置），DMS 就会再次停止复制
误报 — 由于亚马逊云科技 DMS 允许平均延迟并尝试多次尝试验证目标中的数据，因此我们在同步的 153 个表（每天 1 亿笔交易）中观察到所有交易的误报（平均每天 100 条记录）。我们观察到以下误报模式：
- 当源延迟由于数据复制问题而大于阈值时。
- 当变化太多时，会非常频繁地发生。
重新验证记录的错误 -记录被记录为错误后，无法重新验证记录。在持续验证模式下，验证任务按事务日志序列号 (LSN) 处理记录。如果记录未在阈值延迟限制内到达且被记录为错误，则无法重新验证，因为任务的日志序列会向前移动。
重新启动验证任务会对所有数据进行验证 -当仅限验证的任务重新启动时，它会首先验证所有数据，然后再继续验证持续复制的数据。在我们的用例中，验证任务大约需要 30-40 小时才能赶上当前的交易，尤其是对于拥有超过 10 亿条记录的大表。

我们遇到的数据差异场景

让我们来看一些亚马逊云科技 DMS 验证任务无法处理的数据差异场景。让我们研究一下在数据复制过程中如何出现更新异常，如下表所示。

PK	Col1	Col2	DML_TYPE	时间戳	状态	原因
建议1	1	0	插入	3/12/24 9:20	完成了	每 15 秒（可配置）提交一次批处理。这是批次的一部分。
建议1	1	1	更新	3/12/24 9:21	还没完成	它不是该批次的一部分。

由于部署、合并或修复一些持续存在的问题或更改任务设置等原因，任务在 9:20:05 中断。亚马逊云科技 DMS 任务重新启动后，在第一批中，它尝试将插入和更新合并为一次插入，而不是两笔事务。它尝试插入以下记录。

PK	Col1	Col2	DML_TYPE	时间戳
建议1	1	1	更新	3/12/24 9:21

但是，由于该记录已存在于目标中，因此亚马逊云科技 DMS 无法插入该记录，并且该任务因主键约束违规错误而失败。

我们可以在删除异常中观察到类似的行为，如下表所示。

PK	Col1	Col2	DML_TYPE	时间戳	状态	原因
建议1	1	0	插入	3/12/24 9:20	完成了	每 15 秒（可配置）提交一次批处理。这是批次的一部分。
建议1	1	0	删除	3/12/24 9:21	还没完成	每 15 秒（可配置）提交一次批处理。它不是该批次的一部分。

在删除场景中，插入和删除会导致亚马逊云科技 DMS 不执行任何操作，因此源代码更改（在本例中为删除记录）不会应用于目标。

克服额外数据差异情景的步骤

在本节中，我们将讨论为克服亚马逊云科技 DMS 数据验证的这些限制所采取的步骤。尽管可以监控大多数亚马逊云科技 DMS 数据从源到目标的复制，但如果突然出现故障（网络故障或亚马逊云科技区域基础设施故障），亚马逊云科技 DMS 无法自行处理验证。下一节描述了从此类故障中恢复并在灾难恢复后继续保持数据完整性的标准操作程序方法。

定制的重新验证框架可消除误报

在正常情况下，亚马逊云科技 DMS 验证框架不会记录大量误报。但是，正如本文前面所解释的那样，由于记录处于边界状态或延迟，我们观察到误报。每日平均值为每天 100 条记录（在大约 1000 万次更改中）。我们已经建立了一个框架，该框架计划每小时运行一次，并重新验证了直到最后一小时才记录的数据。下图说明了该框架的示例工作流程。

计划在下午 12:00 进行的重新验证任务考虑 DMS 亚马逊云科技验证任务在上午 11:00 之前记录的数据。下次在下午 1:00 运行时会考虑在下午 12:00 之前记录的错误，依此类推。它获取错误记录的源值，并比较运行时目标中的数据。延迟 1 小时是为了适应和消除延迟（最多 1 小时）对验证的影响。对于验证表中的每条记录，重新验证框架会确定它是真阳性还是误报。

下表显示了重新验证后的样本数据。

任务名称

表所有者

表名

failure_time

密钥类型

钥匙

失败类型

详情

目标内可用

与源匹配

上次更新日期时间

上次更新者

12028475

验证任务_1

表所有者

表 1

<failure_1_Timestamp>

行

{
“密钥”：[“4905298532”]}

RECORD_DIFF

<null>[[{'col_1': '3767801528'}, {'col_1': '}<null>], [{' col_2 ': '2023-08-25 20:42:00'}, {'col_2': '2023-08-25 20:27:00 '}], [{' col_3 ':' 900 '}, {' col_3 ':' 0 '}], [{' col_4 ':' out '}, {' col_4 ':' missedOut '}], [{' col_5 ':' 0 '}, {' col_5 ':' 1 '}, [{' col_6 ': '2023-08-26 03:27:53'}, {'col_6': '2023-08-26 03:27:08 '}], [{' col_7 ':' 1 '}, {' col_7 ':'}],]

假的

空

00:00.0

DMS_master

12027282

验证任务_2

表所有者

表 2

<failure_2_Timestamp>

行

{
“密钥”：[“4905285340”]}

MISSING_SOURCE

真的

00:00.0

DMS_master

通过重新验证将错误数量降至最低之后，下图说明了更正过程。

重新验证框架旨在重新验证亚马逊云科技 DMS 验证记录的错误，并最大限度地减少记录为误报的错误。但是，由于以下情况，它无法完全消除误报：

由于数据总是在源和目标系统中移动，因此从亚马逊云科技 DMS 记录错误到验证错误的重新验证框架之间，源数据和目标数据都可能发生了变化
如果复制延迟超过 1 小时，则该过程无法消除误报

当错误数量最小化时，我们会再次手动比较源记录和目标记录，并进行任何必要的更正。

手动更正

如前所述，源和目标位置的数据总是在变化，因此，无论我们何时查询源和目标，总会有时间差异因素。例如，如果自动校正脚本确定需要更正目标中的数据并继续应用校正，则源中的数据可能会在该时间差（检测和校正之间）发生变化。在这种情况下，我们最终可能会与亚马逊云科技 DMS 竞争，后者正在复制数据，因此会使记录不正确。

在手动更正中，我们首先找到记录不匹配的根本原因，并确定它是否可能再次发生变化（在这种情况下，亚马逊云科技 DMS 将自动更正该记录）。如果源事件不可能再次发生，我们将继续手动进行更正。

使用表级筛选器（在审计列上）来验证部分数据

我们已经探讨了在复制中断且需要重新启动任务的情况下验证部分数据的可能性。这需要在表的所有主键列上启用补充日志记录。如果该表没有主键，那么我们需要在审计列上添加补充日志记录（例如 update_date_time）。在没有过滤器的情况下重新启动验证任务将导致其验证所有记录（超过60亿条），并且需要多天才能完成。使用主键和审计列补充日志记录方法，我们只能在需要逐步验证数据的时间段内运行审计，因此只需几分钟或几小时即可检索结果。

结论

在这篇文章中，我们讨论了如何使用兼容亚马逊云科技 DMS 和 Aurora PostgreSQL 来构建和测试数据复制的数据验证框架。我们还介绍了我们在测试中观察到的数据差异情景，并描述了以可控方式处理此类情况的方法。这些措施帮助我们避免源数据库、亚马逊云科技 DMS 或目标数据库的计划外故障导致的数据完整性问题。通过将此自定义框架用于亚马逊云科技 DMS 验证任务，运营团队可以维护数据完整性，这是源数据库和目标数据库之间持续复制的一部分。

Amazon TimeHub团队的AWS DMS博客系列全面概述了使用Amazon Database Migration Service (亚马逊云科技 DMS) 构建强大的数据复制框架的过程。该系列分为四个部分，涵盖了从初始实施到确保数据完整性和弹性的整个过程。第 1 部分介绍了从 Oracle 到兼容 Amazon Aurora PostgreSQL 的版本的低延迟复制解决方案。第 2 部分侧重于设计弹性和高可用性、解决各种故障场景和监控复制运行状况。第 3 部分深入探讨了 Oracle RESETLOGS 面临的具体挑战，以及该团队如何开发恢复框架来应对此类中断。最后，第 4 部分（本文）探讨了在亚马逊云科技 DMS 验证任务之上构建的自定义框架，以在复制期间保持持续的数据完整性。在整个系列中，我们分享了对实现卓越运营的方法（包括监控、恢复流程和数据验证技术）的见解，为在复杂的企业环境中构建和维护可靠的数据复制系统提供了整体视图。

如果您对这篇文章有任何疑问或评论，请在评论部分分享您的想法。