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

# 使用为正在进行的复制创建任务 AWS DMS
<a name="CHAP_Task.CDC"></a>

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

**注意**  
您只能使用完全加载任务迁移视图。如果您的任务是仅 CDC 任务或在完成后启动 CDC 的完全加载任务，则迁移仅包含来自源的表。使用 full-load-only任务，您可以迁移视图或表和视图的组合。有关更多信息，请参阅 [使用 JSON 指定表选择和转换规则](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.md)。

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

 要从源数据库读取正在进行的更改，请 AWS DMS 使用特定于引擎的 API 操作从源引擎的事务日志中读取更改。以下是一些如何 AWS DMS 做到这一点的示例：
+ 对于 Oracle， AWS DMS 使用 Oracle LogMiner API 或二进制读取器 API（bfile API）来读取正在进行的更改。 AWS DMS 根据系统更改编号 (SCN) 从联机或存档重做日志中读取正在进行的更改。
+ 对于微软 SQL Server， AWS DMS 使用 MS-Replication 或 MS-CDC 将信息写入 SQL Server 事务日志。然后，它使用 SQL Server 中的 `fn_dblog()` 或 ` fn_dump_dblog()` 函数，根据日志序列号 (LSN) 读取事务日志中的更改。
+ 对于 MySQL，从基于行的二进制日志（二进制日志）中 AWS DMS 读取更改并将这些更改迁移到目标。
+ 对于 PostgreSQL AWS DMS ，设置逻辑复制槽并使用 test\$1decoding 插件从源读取更改并将其迁移到目标。
+ 对于将 Amazon RDS 作为源的情况，我们建议确保启用了备份以设置 CDC。我们还建议确保源数据库已配置为保留更改日志足够长的时间，通常 24 小时已足够。有关每个端点的特定设置，请参阅以下内容：
  + **Amazon RDS for Oracle：** [为配置由 AWS托管的 Oracle 源 AWS DMS](CHAP_Source.Oracle.md#CHAP_Source.Oracle.Amazon-Managed.Configuration)。
  + **Amazon RDS for MySQL 和 Aurora MySQL：** [使用 AWS托管的 MySQL 兼容数据库作为源 AWS DMS](CHAP_Source.MySQL.md#CHAP_Source.MySQL.AmazonManaged)。
  + **Amazon RDS for SQL Server：** [在云 SQL Server 数据库实例上设置持续复制](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.Configuration)。
  + **Amazon RDS for PostgreSQL 和 Aurora PostgreSQL：**PostgreSQL 自动保留所需的 WAL。

有两种类型的持续复制任务：
+ 完全加载加 CDC – 该任务迁移现有数据，然后根据对源数据库的更改更新目标数据库。
+ 仅 CDC – 当目标数据库上存在数据之后，该任务会迁移持续更改。

## 从 CDC 开始点开始执行复制
<a name="CHAP_Task.CDC.StartPoint"></a>

您可以从多个位置启动 AWS DMS 正在进行的复制任务（仅限更改数据捕获）。这些功能包括：
+  **从自定义 CDC 开始时间开始** — 您可以使用 AWS 管理控制台 或 AWS DMS 提供 AWS CLI 要开始复制的时间戳。 AWS DMS 然后从这个自定义 CDC 开始时间开始执行正在进行的复制任务。 AWS DMS 将给定的时间戳（以 UTC 为单位）转换为本机起点，例如 SQL Server 的 LSN 或 Oracle 的 SCN。 AWS DMS 根据源引擎的更改流，使用特定于引擎的方法来确定从何处开始迁移任务。
**注意**  
只有将`StartFromContext`额外的连接属性设置为所需的时间戳，Db2 作为源才能提供自定义的 CDC 开始时间。  
当 PostgreSQL 作为源时，不支持自定义 CDC 开始时间。这是因为 PostgreSQL 数据库引擎无法将时间戳映射到 LSN 或 SCN，而 Oracle 或 SCN Server 可以。
+ **从 CDC 本机开始点** – 您也可以从源引擎的事务日志中的本机时间点开始。在某些情况下，您可能更喜欢这种方法，因为时间戳可以指示事务日志中的多个原生点。 AWS DMS 以下源端点支持此功能：
  + SQL Server
  + PostgreSQL
  + Oracle
  + MySQL
  + MariaDB
**注意**  
以下数据库端点不支持 CDC 本机起点功能：  
 Amazon Aurora MySQL 
 Amazon Aurora PostgreSQL 
Amazon DocumentDB（兼容 MongoDB）
Amazon S3
IBM Db2 for z/OS
IBM Db2 LUW
Microsoft Azure SQL 数据库
微软 Azure SQL 托管实例
MongoDB
SAP Sybase AS

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

**注意**  
 在指定 CDC（更改数据捕获）起点时，迁移前评估仍将对当前环境中的现有元数据和参数进行全面分析。这样可以确保无论指定的 CDC 起点如何，都能评估所有当前的配置和设置。  
 重要：如果在过去 7 天内未对给定任务进行任何评估，则迁移前评估将在恢复和重新加载模式下自动执行，以确保数据的完整性和一致性。  
 元数据分析仍然是全面的。
 参数评估涵盖当前状态。
 CDC 起点不限制评估范围。
 保持全面的系统配置审查。
 在以下情况下，在恢复和重装模式下自动执行：  
 上次评估时间 > 7 天前。  
 未找到之前的评估记录。
 这有助于确保准确的迁移规划，同时保持指定的 CDC 点和当前系统状态之间的数据一致性。

### 确定 CDC 本机开始点
<a name="CHAP_Task.CDC.StartPoint.Native"></a>

*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 本机开始点，请在参与持续复制的任何表上创建发布。 AWS DMS 在不使用 CDC 本机开始点的情况下使用 CDC 时会自动创建发布。

**PostgreSQL**  
可以对 PostgreSQL 源数据库使用 CDC 恢复检查点。在为源数据库运行持续复制任务（父任务）时，会在各个点生成此检查点值。有关一般检查点的更多信息，请参阅[使用检查点作为 CDC 开始点](#CHAP_Task.CDC.StartPoint.Checkpoint)。  
要确定要用作本机起点的检查点，请使用您的数据库`pg_replication_slots`视图或父任务的概述详细信息 AWS 管理控制台  

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

1. 登录 AWS 管理控制台 并在 [https://console.aws.amazon.com/dms/v2](https://console.aws.amazon.com/dms/v2/)/上打开 AWS DMS 控制台。

   如果以 IAM 用户身份登录，请确保具有适当的 AWS DMS访问权限。有关所需权限的更多信息，请参阅[使用所需的 IAM 权限 AWS DMS](security-iam.md#CHAP_Security.IAMPermissions)。

1. 在导航窗格中，选择 **Database migration tasks (数据库迁移任务)**。

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

1. 在 **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 任务的信息，请参阅[使用 AWS托管的 PostgreSQL 数据库实例启用 CDC AWS DMS](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.RDSPostgreSQL.CDC)。

**Oracle**  
系统更改号 (SCN) 是 Oracle 数据库使用的逻辑内部时间戳。 SCNs 对数据库中发生的事件进行排序，这是满足事务的 ACID 属性所必需的。Oracle 数据库 SCNs 用于标记所有更改已写入磁盘的位置，这样恢复操作就不会应用已写入的更改。Oracle 还使用 SCNs 标记一组数据不存在重做的地方，以便可以停止恢复。  
要获取 Oracle 数据库中的当前 SCN，请运行以下命令。  

```
SELECT CURRENT_SCN FROM V$DATABASE
```
如果您使用 SCN 或时间戳启动 CDC 任务，则会错过所有未完成事务的结果，因此无法迁移这些结果。*未完成事务*是在任务的开始位置之前启动，并在任务开始位置之后提交的事务。您可以标识 SCN 和时间戳，以便在包含所有未完成事务的时间点启动 CDC 任务。有关更多信息，请参阅 Oracle 在线文档中的[事务](https://docs.oracle.com/database/121/CNCPT/transact.htm#CNCPT016)。在 3.5.1 及更高版本中，如果您使用 SCN 或时间戳启动任务，则 AWS DMS 支持使用`openTransactionWindow`端点设置对仅限 CDC 的任务进行未结交易。  
 使用该`openTransactionWindow`设置时，您必须提供以分钟为单位的窗口来处理未结交易。 AWS DMS 移动捕获位置并找到开始数据捕获的新位置。 AWS 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 的更多信息 LSNs，请参阅 [MySQL 文档](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_lsn)。  
 要获取 MySQL 数据库中的当前 LSN，请运行以下命令。  

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

### 使用检查点作为 CDC 开始点
<a name="CHAP_Task.CDC.StartPoint.Checkpoint"></a>

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

您可以通过以下三种方法之一获取检查点信息：
+ 运行 API 操作 `DescribeReplicationTasks` 并查看结果。您可以按任务筛选信息以及搜索检查点。当任务处于停止/失败状态时，您可以检索最新的检查点。如果任务已被删除，则此信息丢失。
+ 查看目标实例上名为 `awsdms_txn_state` 的元数据表。您可以查询表来获取检查点信息。要创建元数据表，请在创建任务时将 `TaskRecoveryTableEnabled` 参数设置为 `Yes`。此设置会导致持续 AWS 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`

### 在提交时间点或服务器时间点停止任务
<a name="CHAP_Task.CDC.StopPoint"></a>

 随着 CDC 原生起点的引入，还 AWS DMS 可以在以下几点停止任务：
+ 源上的提交时间
+ 复制实例上的服务器时间

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

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

### 使用目标重新加载启动任务
<a name="CHAP_Task.CDC.Start.Task"></a>

 您可以使用重新加载选项（DMS API 中的 “重新加载目标”）启动 AWS DMS 迁移现有数据和复制正在进行的更改任务。在这种情况下，迁移将从头开始，重新加载每个表的数据，然后使用满载和启用 CDC 的任务设置继续复制数据。

 要使用任务启动后重新加载选项，必须满足以下条件：
+  必须停止任务。
+  任务的迁移方法必须是完全加载或者完全加载加 CDC。

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

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

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

## 执行双向复制
<a name="CHAP_Task.CDC.Bidirectional"></a>

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

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

**注意**  
AWS DMS 双向复制并不是一个完整的多主机解决方案，包括主节点、冲突解决等。

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

AWS DMS 支持在以下数据库引擎上进行双向复制：
+ Oracle 
+ SQL Server 
+ MySQL 
+ PostgreSQL 
+ Amazon Aurora MySQL 兼容版
+ Aurora PostgreSQL 兼容版

### 创建双向复制任务
<a name="CHAP_Task.CDC.Bidirectional.Tasks"></a>

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

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

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

 AWS DMS 要使用从节点 A 在节点 B 上实例化新数据集（数据库），请执行以下操作：

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

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

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

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

### 防止环回
<a name="CHAP_Task.CDC.Bidirectional.Loopback"></a>

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

接下来，第二个任务 T2 从源数据库 B 读取更改日志，并将其应用回目标数据库 A。在 T2 执行此操作之前，DMS 必须确保不会对源数据库 A 进行从源数据库 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 的 `SourceSchema` 和 `TargetSchema` 设置使用相反的设置指定。

任务 T1 的设置如下所示。

```
{
. . .

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

. . .
}
```

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

```
{
. . .

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

. . .
}
```

**注意**  
使用时 AWS CLI，请仅使用`create-replication-task`或`modify-replication-task`命令在双向复制任务`LoopbackPreventionSettings`中进行配置。

### 双向复制的限制
<a name="CHAP_Task.CDC.Bidirectional.Limitations"></a>

的双向复制 AWS DMS 有以下限制：
+ 环回防护仅跟踪数据操纵语言 (DML) 语句。 AWS DMS 不支持防止数据定义语言 (DDL) 环回。要执行此操作，请配置双向对中的任务之一以筛选出 DDL 语句。
+ 使用环回防护的任务不支持批量提交更改。要配置具有环回防护的任务，请确保 `BatchApplyEnabled` 设置为 `false`。
+ DMS 双向复制不包括冲突检测或解决。要检测数据不一致性，请对这两个任务使用数据验证。
+ `setUpMsCdcForTables` 必须设置为 `true`，SQL Server 源端点才能设置双向复制。