使用 AWS DMS 为持续复制创建任务 - AWS Database Migration Service
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

使用 AWS DMS 为持续复制创建任务

您可以创建一个 AWS DMS 任务来捕获对源数据存储的持续更改。您可以在迁移数据时执行此捕获。您还可以创建一个任务,以便在初始(完全加载)迁移到支持的目标数据存储完成后捕获持续更改。此过程称为持续复制或更改数据捕获 (CDC)。AWS DMS 在从源数据存储复制持续更改时使用此过程。此过程的工作方式是使用数据库引擎的原生 API 来收集对数据库日志的更改。

注意

您只能使用完全加载任务迁移视图。如果您的任务是仅 CDC 任务或在完成后启动 CDC 的完全加载任务,则迁移仅包含来自源的表。使用仅完全加载任务,您可以迁移视图或表和视图的组合。有关更多信息,请参阅 使用 JSON 按表映射指定表选择和转换

每个源引擎有特定的配置要求,用于将此更改流公开到指定用户账户。大部分引擎需要一些额外的配置才能让捕获流程以有意义的方式使用更改数据,而不会丢失数据。例如,Oracle 需要增加补充日志记录,MySQL 需要行级二进制日志记录 (bin logging)。

为了从源数据库读取持续更改,AWS DMS 使用引擎特定的 API 操作从源引擎的事务日志中读取更改。下面是一些 AWS DMS 如何处理的示例:

  • 对于 Oracle,AWS DMS 使用 Oracle LogMiner API 或 Binary Reader API (bfile API) 读取持续更改。AWS DMS 根据系统更改号 (SCN) 从联机或存档重做日志中读取持续更改。

  • 对于 Microsoft SQL Server,AWS DMS 使用 MS-Replication 或 MS-CDC 将信息写入 SQL Server 事务日志。然后,它使用 SQL Server 中的 fn_dblog() fn_dump_dblog() 函数,根据日志序列号 (LSN) 读取事务日志中的更改。

  • 对于 MySQL,AWS DMS 从基于行的二进制日志 (binlog) 读取更改,并将这些更改迁移到目标。

  • 对于 PostgreSQL,AWS DMS 设置逻辑复制槽并使用 test_decoding 插件从源读取更改,并将更改迁移到目标。

  • 对于将 Amazon RDS 作为源的情况,我们建议确保启用了备份以设置 CDC。我们还建议确保源数据库已配置为保留更改日志足够长的时间 — 通常 24 小时已足够。

有两种类型的持续复制任务:

  • 完全加载加 CDC – 该任务迁移现有数据,然后根据对源数据库的更改更新目标数据库。

  • 仅 CDC – 当目标数据库上存在数据之后,该任务将迁移持续更改。

从 CDC 开始点开始执行复制

您可以从多个点启动 AWS DMS 持续复制任务(仅更改数据捕获)。这些功能包括:

  • 从自定义 CDC 开始时间 – 您可使用 AWS 管理控制台或 AWS CLI 为 AWS DMS 提供您希望复制开始的时间戳。之后,AWS DMS 从此自定义 CDC 开始时间启动持续复制任务。AWS DMS 将指定的时间戳(采用 UTC 格式)转换为本机开始点,例如,对于 SQL Server 为 LSN,对于 Oracle 为 SCN。AWS DMS 使用引擎特定的方法,根据源引擎的更改流确定从哪个位置开始迁移任务。

    注意

    当 PostgreSQL 作为源时,不支持自定义 CDC 开始时间。这是因为 PostgreSQL 数据库引擎无法将时间戳映射到 LSN 或 SCN,而 Oracle 或 SCN Server 可以。

  • 从 CDC 本机开始点 – 您也可以从源引擎的事务日志中的本机时间点开始。在某些情况下,您可能首选此方法,因为时间戳可以指出事务日志中的多个本机时间点。AWS DMS 支持此功能用于以下源终端节点:

    • SQL Server

    • PostgreSQL

    • Oracle

    • MySQL

确定 CDC 本机开始点

CDC 本机开始点 是数据库引擎日志中的一个点,定义开始 CDC 的时间。例如,假设批量数据转储已应用于从某个时间点开始的一个目标。在此情况下,您可以从进行转储之前的时间点开始,查找仅持续复制任务的本机开始点。

以下示例演示如何从支持的源引擎查找 CDC 本机开始点:

SQL Server

在 SQL Server 中,日志序列号 (LSN) 分为三个部分:

  • 虚拟日志文件 (VLF) 序列号

  • 日志块的启动偏移量

  • 槽编号

示例 LSN 如下所示:00000014:00000061:0001

要根据事务日志备份设置获取 SQL Server 迁移任务的开始点,请在 SQL Server 中使用 fn_dblog()fn_dump_dblog() 函数。

要将 CDC 本机开始点与 SQL Server 结合使用,您必须为参与持续复制的所有表创建发布。有关创建发布的更多信息,请参阅 为持续复制创建 SQL Server 发布。AWS DMS 将在您使用 CDC、而不使用 CDC 本机开始点时自动创建发布。

PostgreSQL

可以对 PostgreSQL 源数据库使用 CDC 恢复检查点。在为源数据库运行持续复制任务(父任务)时,会在各个点生成此检查点值。有关一般检查点的更多信息,请参阅使用检查点作为 CDC 开始点

要标识要用作本机开始点的检查点,请使用数据库 pg_replication_slots 视图或 AWS 管理控制台中父任务的概述详细信息。

在控制台上查找父任务的概述详细信息

  1. 登录 AWS 管理控制台并通过以下网址打开 AWS DMS 控制台:https://console.amazonaws.cn/dms/v2/

    如果以 AWS Identity and Access Management (IAM) 用户身份登录,请确保具有适当的 AWS DMS 访问权限。有关所需权限的更多信息,请参阅使用 AWS DMS 所需的 IAM 权限

  2. 在导航窗格中,选择 Database migration tasks (数据库迁移任务)

  3. Database migration tasks (数据库迁移任务) 页面上的列表中选择您的父任务。这会打开显示概述详细信息的父任务页面。

  4. Change data capture (CDC) (更改数据捕获 (CDC))Change data capture (CDC) start position (更改数据捕获 (CDC) 开始位置)Change data capture (CDC) recovery checkpoint (更改数据捕获 (CDC) 恢复检查点) 下找到检查点值。

    该值如下面所示。

    checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0

    在这里,4AF/B00000D0 组件是您需要指定此本机 CDC 开始点的组件。当您创建 CDC 任务以在 PostgreSQL 源的此开始点开始复制时,将 DMS API CdcStartPosition 参数设置为此值。有关使用 AWS CLI 创建此 CDC 任务的信息,请参阅 将 CDC 用于 RDS 的 PostgreSQL 数据库实例

Oracle

系统更改号 (SCN) 是由 Oracle 数据库使用的逻辑内部时间戳。SCN 对数据库中发生的事件排序,这是满足事务的 ACID 属性所必需的。Oracle 数据库使用 SCN 标记所有更改写入到磁盘中的位置,这样恢复操作就不会应用已经写入的更改。Oracle 还使用 SCN 标记数据集中不存在重做的点,这样可以停止恢复。有关 Oracle SCNs 的更多信息,请参阅 Oracle 文档

要获取 Oracle 数据库中的当前 SCN,请运行以下命令:

SELECT current_scn FROM V$DATABASE
MySQL

在 MySQL 版本 5.6.3 发行之前,MySQL 的日志序列号 (LSN) 为 4 字节的无符号整数。在 MySQL 版本 5.6.3 中,重做日志文件大小限制从 4 GB 增加到 512 GB,因此 LSN 将成为 8 字节的无符号整数。这种增长体现了存储超大信息所需的额外字节。对于在 MySQL 5.6.3 或更高版本上生成的应用程序,如果使用 LSN 值,则应该使用 64 位而非 32 位变量来存储和比较 LSN 值。有关 MySQL LSN 的更多信息,请参阅 MySQL 文档

要获取 MySQL 数据库中的当前 LSN,请运行以下命令:

mysql> show master status;

该查询返回二进制日志文件名、位置以及多个其他值。CDC 本机开始点是二进制日志文件名和位置的组合,例如 mysql-bin-changelog.000024:373。在此示例中,mysql-bin-changelog.000024 是二进制日志文件名,373 是 AWS DMS 需要开始捕获更改的位置。

使用检查点作为 CDC 开始点

持续复制任务将迁移更改,而 AWS DMS 将不断缓存特定于 AWS DMS 的检查点信息。AWS DMS 创建的检查点包含信息,因此复制引擎知道更改流的恢复点。您可以使用检查点返回到更改时间表中的某个点,以及恢复失败的迁移任务。您也可以使用检查点,以在任意指定时间为其他目标启动另一个持续复制任务。

您可以通过以下两种方法之一获取检查点信息:

  • 运行 API 命令 DescribeReplicationTasks 并查看结果。您可以按任务筛选信息以及搜索检查点。当任务处于停止/失败状态时,您可以检索最新的检查点。

  • 查看目标实例上名为 awsdms_txn_state 的元数据表。您可以查询表来获取检查点信息。要创建元数据表,请在创建任务时将 TaskRecoveryTableEnabled 参数设置为 Yes。此设置导致 AWS DMS 连续将检查点信息写入目标元数据表。如果任务已删除,则此信息丢失。

    例如,以下是元数据表中的示例检查点:checkpoint:V1#34#00000132/0F000E48#0#0#*#0#121

在提交时间点或服务器时间点停止任务

通过引入 CDC 本机开始点,AWS DMS 还可以在以下点停止任务:

  • 源上的提交时间

  • 复制实例上的服务器时间

您可以修改某个任务,并根据需要使用 UTC 格式设置停止时间。该任务根据您设置的提交时间或服务器时间自动停止。或者,如果您知道合适的停止迁移任务时间,您也可在创建任务时设置停止时间。

执行双向复制

您可以使用 AWS DMS 任务在两个系统之间执行双向复制。在双向复制 中,您在两个系统之间在两个方向上复制同一个表(或同一组表)中的数据。

例如,您可以将 EMPLOYEE 表从数据库 A 复制到数据库 B,并将对此表的更改从数据库 A 复制到数据库 B。您还可以将对此 EMPLOYEE 表的更改从数据库 B 复制回到 A。因此,您正在执行双向复制。

注意

AWS DMS 双向复制不适合用作完整的多主数据库解决方案(包括主节点、冲突解决等)。

对于对不同节点上的数据进行操作隔离的情况,使用双向复制。换句话说,假设在节点 A 上运行的应用程序更改了一个数据元素,并且节点 A 与节点 B 执行双向复制。节点 A 上的该数据元素永远不会被在节点 B 上运行的任何应用程序更改。

AWS DMS 版本 3.3.1 及更高版本支持在以下数据库引擎上进行双向复制:

  • Oracle

  • SQL Server

  • MySQL

  • PostgreSQL

  • Amazon Aurora 与 MySQL 的兼容性

  • 与 PostgreSQL 兼容的 Aurora

创建双向复制任务

要启用 AWS DMS 双向复制,请为两个数据库(A 和 B)配置源终端节点和目标终端节点。例如,配置数据库 A 的源终端节点、数据库 B 的源终端节点、数据库 A 的目标终端节点和数据库 B 的目标终端节点。

然后创建两个任务:一个任务用于源 A 将数据移到目标 B,另一个任务用于源 B 将数据移到目标 A。此外,请确保为每个任务配置了环回防护。这样做可以防止将完全相同的更改应用于两个任务的目标,这样会损坏其中至少一个任务的数据。有关更多信息,请参阅 防止环回

最简单的方法是从数据库 A 和数据库 B 上的相同数据集开始,然后创建两个仅 CDC 任务,一个任务将数据从 A 复制到 B,另一个任务将数据从 B 复制到 A。

要使用 AWS DMS 从节点 A 实例化节点 B 上的新数据集(数据库),请执行以下操作:

  1. 使用完全加载和 CDC 任务将数据从数据库 A 移到 B。确保在此期间没有任何应用程序正在修改数据库 B 上的数据。

  2. 当完全加载完成并且在允许应用程序修改数据库 B 上的数据之前,请记下数据库 B 的时间或 CDC 开始位置。有关说明,请参阅 从 CDC 开始点开始执行复制

  3. 创建仅 CDC 任务,此任务使用此开始时间或 CDC 开始位置将数据从数据库 B 移回 A。

注意

双向对中只有一个任务可以是完全加载和 CDC。

防止环回

要显示防止环回,假设在任务 T1 中,AWS DMS 从源数据库 A 读取更改日志,并将更改应用于目标数据库 B。

接下来,第二个任务 T2 从源数据库 B 读取更改日志,并将其应用回目标数据库 A。在 T2 执行此操作之前,DMS 必须确保不会对源数据库 B 进行从源数据库 A 对目标数据库 B 所做的相同更改。换句话说,DMS 必须确保这些更改不会回显(环回)到目标数据库 A。否则,数据库 A 中的数据可能会被破坏。

要防止环回更改,请将以下任务设置添加到每个双向复制任务。这样做可以确保不会在任何一个方向发生环回数据损坏。

{ . . . "LoopbackPreventionSettings": { "EnableLoopbackPrevention": Boolean, "SourceSchema": String, "TargetSchema": String }, . . . }

LoopbackPreventionSettings 任务设置确定事务是新事务还是来自反向复制任务的回显。当 AWS DMS 将事务应用于目标数据库时,它会更新 DMS 表 (awsdms_loopback_prevention),并指示更改。在将每个事务应用于目标之前,DMS 会忽略包含对此 awsdms_loopback_prevention 表的引用的任何事务。因此,它不应用更改。

将这些任务设置包括在双向对中的每个复制任务中。这些设置启用环回防护。它们还为包含每个终端节点的 awsdms_loopback_prevention 表的任务中的每个源数据库和目标数据库指定架构。

要使每个任务能够识别并丢弃回显,请将 EnableLoopbackPrevention 设置为 true。要在包含 awsdms_loopback_prevention 的源处指定架构,请将 SourceSchema 设置为源数据库中该架构的名称。要在包含同一个表的目标处指定架构,请将 TargetSchema 设置为目标数据库中该架构的名称。

在以下示例中,复制任务 T1 及其反向复制任务 T2 的 SourceSchemaTargetSchema 设置使用相反的设置指定。

任务 T1 的设置如下所示。

{ . . . "LoopbackPreventionSettings": { "EnableLoopbackPrevention": true, "SourceSchema": "LOOP-DATA", "TargetSchema": "loop-data" }, . . . }

反向任务 T2 的设置如下所示。

{ . . . "LoopbackPreventionSettings": { "EnableLoopbackPrevention": true, "SourceSchema": "loop-data", "TargetSchema": "LOOP-DATA" }, . . . }
注意

使用 AWS CLI 时,请仅使用 create-replication-taskmodify-replication-task 命令在双向复制任务中配置 LoopbackPreventionSettings

双向复制的限制

AWS DMS 的双向复制具有以下限制:

  • 环回防护仅跟踪数据操作语言 (DML) 语句。AWS DMS 不支持阻止数据定义语言 (DDL) 环回。要执行此操作,请配置双向对中的任务之一以筛选出 DDL 语句。

  • 使用环回防护的任务不支持批量提交更改。要配置具有环回防护的任务,请确保 BatchApplyEnabled 设置为 false

  • DMS 双向复制不包括冲突检测或解决。要检测数据不一致性,请对这两个任务使用数据验证。