View a markdown version of this page

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

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

使用创建用于持续复制的任务 Amazon DMS

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

注意

Amazon DMS CDC 不提供实时复制。复制延迟因源工作负载、网络条件、复制实例资源、目标摄取容量和数据特征而异。没有针对 CDC 延迟的 SLA。延迟可能会增加到几分钟或更长时间,具体取决于这些因素。有关更多信息,请参阅 持续复制。

注意

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

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

要从源数据库读取正在进行的更改,请 Amazon DMS 使用特定于引擎的 API 操作从源引擎的事务日志中读取更改。以下是一些如何 Amazon DMS 做到这一点的例子:

  • 对于 Oracle 来说, Amazon DMS 使用 Oracle LogMiner API 或二进制读取器 API(bfile API)来读取正在进行的更改。 Amazon DMS 根据系统更改编号 (SCN) 从在线或存档重做日志中读取正在进行的更改。

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

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

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

  • 对于将 Amazon RDS 作为源的情况,我们建议确保启用了备份以设置 CDC。我们还建议确保源数据库已配置为保留更改日志足够长的时间,通常 24 小时已足够。有关每个端点的特定设置,请参阅以下内容:

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

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

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

从 CDC 开始点开始执行复制

您可以从多个点开始 Amazon DMS 正在进行的复制任务(仅限更改数据捕获)。这些功能包括:

  • 从自定义 CDC 开始时间开始 — 您可以使用 Amazon Web Services 管理控制台 或 Amazon DMS 提供 Amazon CLI 要开始复制的时间戳。 Amazon DMS 然后从这个自定义 CDC 开始时间开始正在进行的复制任务。 Amazon DMS 将给定的时间戳(世界标准时间)转换为本地起点,例如 SQL Server 的 LSN 或 Oracle 的 SCN。 Amazon DMS 使用特定于引擎的方法根据源引擎的更改流确定从何处启动迁移任务。

    注意

    只有将StartFromContext额外的连接属性设置为所需的时间戳,作为源的 Db2 才能提供自定义 CDC 的启动时间。

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

  • 从 CDC 本机开始点 – 您也可以从源引擎的事务日志中的本机时间点开始。在某些情况下,您可能更喜欢这种方法,因为时间戳可以指示事务日志中的多个本地点。 Amazon DMS 支持以下源端点的此功能:

    • SQL Server

    • PostgreSQL

    • Amazon Aurora PostgreSQL

    • Oracle

    • MySQL

    • Amazon Aurora MySQL

    • MariaDB

    注意

    以下数据库端点不支持 CDC 本机起点功能:

    • Amazon DocumentDB(兼容 MongoDB)

    • Amazon S3

    • IBM Db2 for z/OS

    • IBM Db2 LUW

    • Microsoft Azure SQL 数据库

    • 微软 Azure SQL 管理实例

    • MongoDB

    • SAP Sybase ASE

创建任务时, Amazon DMS 标记 CDC 起点,且无法更改。要使用不同的 CDC 开始点,请创建新任务。

注意

在指定 CDC(变更数据捕获)起点时,迁移前评估仍将对当前环境中的现有元数据和参数进行全面分析。这可确保对所有当前配置和设置进行评估,无论指定的 CDC 起点如何。

重要:如果在过去 7 天内没有对给定任务进行过评估,则迁移前评估将在恢复和重新加载模式下自动执行,以确保数据的完整性和一致性。

技术细节:
  • 元数据分析仍然全面。

  • 参数评估涵盖当前状态。

  • CDC 起点不限制评估范围。

  • 保留了完整的系统配置审查。

  • Auto-execution 在恢复和重新加载模式下,如果:

    上次评估 > 7 天前。

    未找到以前的评估记录。

这有助于确保准确的迁移规划,同时保持指定的 CDC 点和当前系统状态之间的数据一致性。

确定 CDC 本机开始点

CDC 本机开始点 是数据库引擎日志中的一个点,定义开始 CDC 的时间。例如,假设批量数据转储已应用于目标。您可以查找持续仅复制任务的本机开始点。为避免任何数据不一致,请谨慎选择仅复制任务的开始点。DMS 会捕获在选定 CDC 开始点之后开始的事务。

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

SQL Server

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

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

  • 日志块的启动偏移量

  • 槽编号

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

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

要在 SQL Server 中使用 CDC 本机开始点,请在参与持续复制的任何表上创建发布。 Amazon DMS 在不使用 CDC 本机开始点的情况下使用 CDC 时会自动创建发布。

PostgreSQL

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

要确定要用作本地起点的检查点,请使用数据库pg_replication_slots视图或父任务的概述详细信息 Amazon Web Services 管理控制台

在控制台上查找父任务的概述详细信息
  1. 登录 Amazon Web Services 管理控制台 并打开 Amazon DMS 控制台,地址为https://console.aws.amazon.com/dms/v2/。

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

  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 参数设置为此值。有关使用创建 Amazon CLI 此 CDC 任务的信息,请参阅使用以下方式启用 CDC Amazon-使用-托管 PostgreSQL 数据库实例 Amazon DMS。

Oracle

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

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

SELECT CURRENT_SCN FROM V$DATABASE

如果您使用 SCN 或时间戳启动 CDC 任务,则会错过所有未完成事务的结果,因此无法迁移这些结果。未完成事务是在任务的开始位置之前启动,并在任务开始位置之后提交的事务。您可以标识 SCN 和时间戳,以便在包含所有未完成事务的时间点启动 CDC 任务。有关更多信息,请参阅 Oracle 在线文档中的事务。在 3.5.1 及更高版本中,如果您使用 SCN 或时间戳启动 CDC-only 任务,则 Amazon DMS 支持使用openTransactionWindow终端节点设置为任务打开事务。

使用该openTransactionWindow设置时,必须提供处理未结交易的窗口(以分钟为单位)。 Amazon DMS 移动捕获位置并找到新位置以开始数据采集。 Amazon DMS 使用新的起始位置扫描所需的 Oracle 重做日志或存档重做日志中的所有未完成事务。

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也是 Amazon DMS 需要开始捕获更改的位置。

使用检查点作为 CDC 开始点

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

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

  • 运行 API 操作 DescribeReplicationTasks 并查看结果。您可以按任务筛选信息以及搜索检查点。当任务处于停止/失败状态时,您可以检索最新的检查点。如果任务已被删除,则此信息丢失。

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

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

  • 在导航窗格中选择数据库迁移任务,然后从“数据库迁移任务”页面上显示的列表中选择您的父任务。会打开显示概述详细信息的父任务页面。在 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

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

随着CDC原生起点的引入,还 Amazon DMS 可以在以下几点停止任务:

  • 源上的提交时间

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

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

注意

首次启动新的 Amazon DMS 无服务器复制时,可能需要 40 分钟才能初始化所有资源。请注意,server_time 选项仅在资源初始化完成后才适用。

使用目标重装启动任务

您可以使用重装选项(DMS API 中的 “重新加载目标”)启动 Amazon DMS 迁移现有数据和复制正在进行的更改任务。在这种情况下,迁移将从头开始,重新加载每个表的数据,并使用满负载和 CDC-enabled 任务设置继续进行数据复制。

要使用带有重新加载选项的任务启动,必须满足以下条件:

  • 该任务必须停止。

  • 任务的迁移方法必须是完全加载或者完全加载加 CDC。

DMS 在重新加载 TargetTablePrepMode 表格之前应用该设置。如果设置TargetTablePrepMode为DO_NOTHING,则必须先手动截断表。

注意

当使用目标重装选项启动 DMS 任务时,迁移前评估将对当前环境中的现有元数据和参数进行全面分析。这可确保评估所有当前配置和设置,无论实际任务状态如何。

重要

如果在过去 7 天内没有对给定任务进行过评估,则迁移前评估将自动执行,以确保数据的完整性和一致性。

执行双向复制

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

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

注意

Amazon DMS 双向复制不打算作为包括主节点、冲突解决方案等在内的完整多主解决方案。

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

Amazon DMS 支持在这些数据库引擎上进行双向复制:

  • Oracle

  • SQL Server

  • MySQL

  • PostgreSQL

  • 亚马逊 Aurora MySQL-Compatible 版

  • 极光 PostgreSQL-Compatible 版

创建双向复制任务

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

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

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

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

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

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

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

注意

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

防止环回

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

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

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

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

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

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

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

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

任务 T1 的设置如下所示。

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

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

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

使用时 Amazon CLI,仅使用create-replication-task或modify-replication-task命令在双向复制任务LoopbackPreventionSettings中进行配置。

双向复制的限制

的双向复制 Amazon DMS 有以下限制:

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

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

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

  • setUpMsCdcForTables 必须设置为 true,SQL Server 源端点才能设置双向复制。