# 使用 Amazon Aurora PostgreSQL 进行复制
接下来，可以找到有关使用 Amazon Aurora PostgreSQL 进行复制的信息，包括如何监控和使用逻辑复制。
**Topics**
+ [使用 Aurora 副本](#AuroraPostgreSQL.Replication.Replicas)
+ [提高 Aurora 副本的读取可用性](#AuroraPostgreSQL.Replication.Replicas.SRO)
+ [监控 Aurora PostgreSQL 复制](#AuroraPostgreSQL.Replication.Monitoring)
+ [使用 Aurora 进行 PostgreSQL 逻辑复制的概述](AuroraPostgreSQL.Replication.Logical.md)
+ [为 Aurora PostgreSQL 数据库集群设置逻辑复制](AuroraPostgreSQL.Replication.Logical.Configure.md)
+ [关闭逻辑复制](AuroraPostgreSQL.Replication.Logical.Stop.md)
+ [监控 Aurora PostgreSQL 逻辑复制的直写缓存和逻辑插槽](AuroraPostgreSQL.Replication.Logical-monitoring.md)
+ [示例：将逻辑复制与 Aurora PostgreSQL 数据库集群结合使用](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)
+ [示例：使用 Aurora PostgreSQL 和 AWS Database Migration Service 的逻辑复制](AuroraPostgreSQL.Replication.Logical.DMS-Example.md)
+ [为逻辑复制连接配置 IAM 身份验证](AuroraPostgreSQL.Replication.Logical.IAM-auth.md)
## 使用 Aurora 副本
*Aurora 副本*是 Aurora 数据库集群中的独立端点，最适合用于扩展读取操作以及提高可用性。Aurora 数据集群可以包含位于 Aurora 数据库集群AWS区域的整个可用区中的最多 15 Aurora 个副本。
数据库集群卷由该数据库集群的多个数据副本组成。不过，集群卷中的数据，对于主要写入器数据库实例和数据库集群中的 Aurora 副本表示为单个逻辑卷。有关 Aurora 副本的更多信息，请参阅 [Aurora 副本](Aurora.Replication.md#Aurora.Replication.Replicas)。
Aurora 副本十分适用于读取扩展，因为它们完全专用于集群卷上的读取操作。写入器数据库实例管理写入操作。集群卷在 Aurora PostgreSQL 数据库集群中的所有实例之间共享。因此，无需额外地复制每个 Aurora 副本的数据副本。
对于 Aurora PostgreSQL，在删除 Aurora 副本时，系统将立即删除其实例端点，并将 Aurora 副本从读取器端点中删除。如果在正待删除的 Aurora 副本上运行语句，则有 3 分钟宽限期。现有语句可在此宽限期内正常完成。当此宽限期结束后，将关闭并删除 Aurora 副本。
Aurora PostgreSQL 数据库集群支持不同 AWS 区域中使用 Aurora Global Database 的 Aurora 副本。有关更多信息，请参阅 [使用 Amazon Aurora Global Database](aurora-global-database.md)。
**注意**
有了读取可用性功能后，如果您想在数据库集群中重启 Aurora 副本，必须手动执行此操作。对于在此功能之前创建的数据库集群，重启写入器数据库实例会自动重启 Aurora 副本。自动重启将重新建立可以保证整个数据库集群读取/写入一致性的入口点。
## 提高 Aurora 副本的读取可用性
Aurora PostgreSQL 通过在写入器数据库实例重新启动或 Aurora 副本无法跟上写入流量时持续提供读取请求，来提高数据库集群的读取可用性。
默认情况下，读取可用性功能在以下版本的 Aurora PostgreSQL 上可用：
+ 16.1 及所有更高版本
+ 15.2 及更高的 15 版本
+ 14.7 及更高的 14 版本
+ 13.10 及更高的 13 版本
+ 12.14 及更高的 12 版本
Aurora Global Database 的以下版本支持读取可用性功能：
+ 16.1 及所有更高版本
+ 15.4 及更高的 15 版本
+ 14.9 及更高的 14 版本
+ 13.12 及更高的 13 版本
+ 12.16 及更高的 12 版本
对于在推出读取可用性功能之前在其中一个版本上创建的数据库集群，要使用该功能，请重新启动数据库集群的写入器实例。
修改 Aurora PostgreSQL 数据库集群的静态参数时，必须重新启动编写器实例，以便参数更改生效。例如，当您设置 `shared_buffers` 的值时，必须重新启动写入器实例。利用 Aurora 副本的读取可用性功能，数据库集群可保持改进的可用性，减少重启写入器实例所带来的影响。读取器实例不会重新启动和继续响应读取请求。要应用静态参数更改，请重启每个单独的读取器实例。
Aurora PostgreSQL 数据库集群的 Aurora 副本可以通过在与写入器重新连接后快速恢复到内存数据库状态，从写入器重新启动、失效转移、缓慢复制和网络问题等复制错误中恢复。这种方法允许 Aurora 副本实例在客户端数据库仍然可用时与最新的存储更新保持一致。
与复制恢复冲突的正在进行的事务可能会收到错误，但客户端可以在读取器赶上写入器后重试这些事务。
### 监控 Aurora 副本
从写入器断开连接中恢复时，您可以监控 Aurora 副本。使用以下指标检查有关读取器实例的最新信息，并跟踪进行中的只读事务。
+ `aurora_replica_status` 函数会更新，以便在读取器实例仍处于连接状态时返回该实例的最新信息。对于与用于执行查询的数据库实例对应的行，`aurora_replica_status` 中的最后一次更新时间戳始终为空。这表明读取器实例具有最新的数据。
+ 当 Aurora 副本与写入器实例断开连接并重新连接时，会发出以下数据库事件：
`Read replica has been disconnected from the writer instance and reconnected.`
+ 当由于恢复冲突而取消了只读查询时，您可能会在数据库错误日志中看到以下一条或多条错误消息：
`Canceling statement due to conflict with recovery`.
`User query may not have access to page data to replica disconnect.`
`User query might have tried to access a file that no longer exists.`
`When the replica reconnects, you will be able to repeat your command.`
### 限制
以下限制适用于具有读取可用性功能的 Aurora 副本：
+ 如果在复制恢复期间无法从写入器实例流式传输数据，则可以重新启动辅助数据库集群的 Aurora 副本。
+ 如果一个 Aurora 副本已在进行中并将重新启动，则 Aurora 副本不支持在线复制恢复。
+ 当您的数据库实例接近事务 ID 重叠时，Aurora 副本将重新启动。有关事务 ID 重叠的更多信息，请参阅[防止事务 ID 重叠故障](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND )。
+ 在某些情况下，当复制过程受阻时，Aurora 副本可能重新启动。
## 监控 Aurora PostgreSQL 复制
读取扩展和高可用性依赖于尽可能短的滞后时间。您可以通过监控 Amazon CloudWatch `ReplicaLag` 指标来监控 Aurora 副本滞后于 Aurora PostgreSQL 数据库集群写入器数据库实例的时间。由于 Aurora 副本从写入器数据库实例所在的同一个集群卷读取数据，因此 `ReplicaLag` 指标对于 Aurora PostgreSQL 数据库集群有不同的含义。Aurora 副本的 `ReplicaLag` 指标表示 Aurora 副本的页面缓存相较写入器数据库实例页面缓存的滞后时间。
有关监控 RDS 实例和 CloudWatch 指标的更多信息，请参阅[监控 Amazon Aurora 集群中的指标](MonitoringAurora.md)。
# 使用 Aurora 进行 PostgreSQL 逻辑复制的概述
通过将 PostgreSQL 的逻辑复制功能与 Aurora PostgreSQL 数据库集群结合使用，您可以复制和同步各个表而不是整个数据库实例。逻辑复制使用发布和订阅模型将更改从源复制到一个或多个接收者。它的工作原理是使用 PostgreSQL 预写日志（WAL）中的更改记录。源或*发布者*将指定表的 WAL 数据发送给一个或多个接收者（*订阅者*），从而复制更改并使订阅者的表与发布者的表保持同步。来自发布者的一组更改使用*发布*来识别。订阅者通过创建*订阅*（用于定义与发布者数据库及其发布内容的连接）来获取更改。*复制插槽*是该方案中用于跟踪订阅进度的机制。
对于 Aurora PostgreSQL 数据库集群，WAL 记录保存在 Aurora 存储中。在逻辑复制场景中充当发布者的 Aurora PostgreSQL 数据库集群从 Aurora 存储中读取 WAL 数据，对其进行解码，然后将其发送给订阅者，以便可以将更改应用于该实例上的表。发布者使用*逻辑解码器*对数据进行解码以供订阅者使用。原定设置情况下，Aurora PostgreSQL 数据库集群在发送数据时使用原生 PostgreSQL `pgoutput` 插件。提供了其他逻辑解码器。例如，Aurora PostgreSQL 还支持将 WAL 数据转换为 JSON 的 `[wal2json](https://github.com/eulerto/wal2json)` 插件。
从 Aurora PostgreSQL 版本 14.5、13.8、12.12 和 11.17 起，Aurora PostgreSQL 使用*直写缓存*增强了 PostgreSQL 逻辑复制过程以提高性能。WAL 事务日志本地缓存在缓冲区中，以减少磁盘输入/输出量，即在逻辑解码期间从 Aurora 存储中读取。每当您对 Aurora PostgreSQL 数据库集群使用逻辑复制时，原定设置情况下使用直写缓存。Aurora 提供了多种可用于管理缓存的函数。有关更多信息，请参阅 [监控 Aurora PostgreSQL 逻辑复制直写缓存](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache)。
所有当前可用的 Aurora PostgreSQL 版本都支持逻辑复制。有关更多信息，请参阅《Aurora PostgreSQL 版本注释》**中的 [Amazon Aurora PostgreSQL 更新](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html)。
适用于 Aurora PostgreSQL 的 Babelfish 支持从以下版本进行逻辑复制：
+ 15.7 及更高版本
+ 16.3 及更高版本
**注意**
除了 PostgreSQL 10 中引入的原生 PostgreSQL 逻辑复制功能外，Aurora PostgreSQL 还支持 `pglogical` 扩展。有关更多信息，请参阅 [使用 pglogical 跨实例同步数据](Appendix.PostgreSQL.CommonDBATasks.pglogical.md)。
有关 PostgreSQL 逻辑复制的更多信息，请参阅 PostgreSQL 文档中的[逻辑复制](https://www.postgresql.org/docs/current/logical-replication.html)和[逻辑解码概念](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html)。
**注意**
PostgreSQL 16 增加了对从只读副本进行逻辑解码的支持。Aurora PostgreSQL 不支持此功能。
# 为 Aurora PostgreSQL 数据库集群设置逻辑复制
设置逻辑复制需要 `rds_superuser` 权限。Aurora PostgreSQL 数据库集群必须配置为使用自定义数据库集群参数组，以便您可以设置必要的参数，详见以下过程。有关更多信息，请参阅 [Amazon Aurora 数据库集群的数据库集群参数组](USER_WorkingWithDBClusterParamGroups.md)。
**为 Aurora PostgreSQL 数据库集群设置 PostgreSQL 逻辑复制**
1. 登录 AWS 管理控制台 并通过以下网址打开 Amazon RDS 控制台：[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)。
1. 在导航窗格中，选择您的 Aurora PostgreSQL 数据库集群。
1. 打开 **Configuration**（配置）选项卡。在实例详细信息中，找到包含**类型**为**数据库集群参数组**的**参数组**链接。
1. 选择此链接以打开与 Aurora PostgreSQL 数据库集群关联的自定义参数。
1. 在 **Parameters**（参数）搜索字段中，键入 `rds` 以查找 `rds.logical_replication` 参数。此参数的原定设置值为 `0`，这意味着它在原定设置情况下处于关闭状态。
1. 选择 **Edit parameters**（编辑参数）以访问属性值，然后从选择器中选择 `1` 以开启该功能。根据您的预期使用情况，您可能还需要更改以下参数的设置。但是，在许多情况下，原定设置值就足够了。
+ `max_replication_slots` – 将此参数设置为至少等于您计划的逻辑复制发布和订阅总数的值。如果您正在使用 AWS DMS，则此参数应至少等于集群中计划的更改数据捕获任务数加上逻辑复制发布和订阅数。
+ `max_wal_senders` 和 `max_logical_replication_workers` – 将这些参数设置为至少与您打算激活的逻辑复制插槽数量或更改数据捕获的活动 AWS DMS 任务数量相等的值。使逻辑复制插槽处于非活动状态可防止 vacuum 从表中删除过时的元组，因此，我们建议您监视复制插槽，并根据需要删除非活动的插槽。
+ `max_worker_processes` – 将此参数设置为至少等于 `max_logical_replication_workers`、`autovacuum_max_workers` 和 `max_parallel_workers` 值的总和的值。在小型数据库实例类上，后台工件进程可能会影响应用程序工作负载，因此，如果将 `max_worker_processes` 设置为高于原定设置值，请监控数据库的性能。（原定设置值是 `GREATEST(${DBInstanceVCPU*2},8}` 的结果，这意味着，在原定设置情况下，这是 8 或数据库实例类的 CPU 等效量的 2 倍，以较大者为准）。
**注意**
您可以修改客户创建的数据库参数组中的参数值，但不能更改原定设置数据库参数组中的参数值。
1. 选择**保存更改**。
1. 重启 Aurora PostgreSQL 数据库集群的写入器实例，以使更改生效。在 Amazon RDS 控制台中，选择集群的主数据库实例，然后从 **Actions**（操作）菜单中选择 **Reboot**（重启）。
1. 当实例可用时，您可以验证逻辑复制是否已开启，如下所示。
1. 使用 `psql` 连接到 Aurora PostgreSQL 数据库集群的写入器实例。
```
psql --host=your-db-cluster-instance-1.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. 使用以下命令验证逻辑复制是否已启用。
```
labdb=> SHOW rds.logical_replication;
rds.logical_replication
-------------------------
on
(1 row)
```
1. 验证 `wal_level` 设置为 `logical`。
```
labdb=> SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
有关使用逻辑复制使数据库表与来自源 Aurora PostgreSQL 数据库集群的更改保持同步的示例，请参阅 [示例：将逻辑复制与 Aurora PostgreSQL 数据库集群结合使用](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)。
# 关闭逻辑复制
完成复制任务后，应停止复制过程，删除复制插槽并关闭逻辑复制。在删除插槽之前，请确保不再需要它们。无法删除活动的复制插槽。
**关闭逻辑复制**
1. 删除所有复制插槽。
要删除所有复制插槽，请连接到发布者并运行以下 SQL 命令。
```
SELECT pg_drop_replication_slot(slot_name)
FROM pg_replication_slots
WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);
```
运行此命令时，复制插槽不能处于活动状态。
1. 修改与发布者关联的自定义数据库集群参数组（如[为 Aurora PostgreSQL 数据库集群设置逻辑复制](AuroraPostgreSQL.Replication.Logical.Configure.md)详述），但将 `rds.logical_replication` 参数设置为 0。
有关自定义数据库参数组的更多信息，请参阅[在 Amazon Aurora 中修改数据库集群参数组中的参数](USER_WorkingWithParamGroups.ModifyingCluster.md)。
1. 重启发布者 Aurora PostgreSQL 数据库集群，以使对 `rds.logical_replication` 参数的更改生效。
# 监控 Aurora PostgreSQL 逻辑复制的直写缓存和逻辑插槽
监控逻辑复制直写缓存并管理逻辑插槽，以提高 Aurora PostgreSQL 数据库集群的性能。接下来，查找有关直写缓存和逻辑插槽的更多信息。
**Topics**
+ [监控 Aurora PostgreSQL 逻辑复制直写缓存](#AuroraPostgreSQL.Replication.Logical-write-through-cache)
+ [管理 Aurora PostgreSQL 的逻辑插槽](#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)
## 监控 Aurora PostgreSQL 逻辑复制直写缓存
原定设置情况下，Aurora PostgreSQL 版本 14.5、13.8、12.12 和 11.17 及更高版本使用直写缓存来提高逻辑复制的性能。如果没有直写缓存，Aurora PostgreSQL 在实现原生 PostgreSQL 逻辑复制过程时使用 Aurora 存储层。为此，它将 WAL 数据写入存储，然后从存储中读回数据以对其进行解码并发送（复制）到其目标（订阅者）。这可能会导致在 Aurora PostgreSQL 数据库集群的逻辑复制过程中出现瓶颈。
直写缓存尽可能减少了对 Aurora 存储层的依赖。Aurora PostgreSQL 并不始终在该层进行写入和读取，而是使用缓冲区来缓存逻辑 WAL 流以便在复制过程中使用，从而减少了访问磁盘的需求。该缓冲区是逻辑复制中使用的原生 PostgreSQL 缓存，在 Aurora PostgreSQL 数据库集群参数中标识为 `rds.logical_wal_cache`。
当您在 Aurora PostgreSQL 数据库集群（对于支持直写缓存的版本）中使用逻辑复制时，您可以监控缓存命中率以查看其对您的使用案例的效果有多好。为此，请使用 `psql` 连接到 Aurora PostgreSQL 数据库集群的写入实例，然后使用 Aurora 函数 `aurora_stat_logical_wal_cache`，如以下示例所示。
```
SELECT * FROM aurora_stat_logical_wal_cache();
```
该函数返回如下输出。
```
name | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
-----------+------------+-----------+------------+-----------+----------+--------------
test_slot1 | 79183 | 24 | 0 | 24 | 100.00% | 2022-08-05 17:39...
test_slot2 | | 1 | 0 | 1 | 100.00% | 2022-08-05 17:34...
(2 rows)
```
为了便于阅读，已缩短了 `last_reset_timestamp` 值。有关此函数的更多信息，请参阅 [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md)。
Aurora PostgreSQL 提供了以下两个用于监控直写缓存的函数。
+ `aurora_stat_logical_wal_cache` 函数 – 有关参考文档，请参阅 [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md)。
+ `aurora_stat_reset_wal_cache` 函数 – 有关参考文档，请参阅 [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md)。
如果您发现自动调整的 WAL 缓存大小不足以满足您的工作负载，则可以手动更改 `rds.logical_wal_cache` 的值。请考虑以下事项：
+ 当 `rds.logical_replication` 参数禁用时，`rds.logical_wal_cache` 设置为零（0）。
+ 当 `rds.logical_replication` 参数启用时，`rds.logical_wal_cache` 默认值为 16 MB。
+ `rds.logical_wal_cache` 参数是静态的，并需要重新启动数据库实例以使更改生效。根据 8 Kb 数据块定义此参数。请注意，任何小于 32 Kb 的正值均视为 32 Kb。有关 `wal_buffers` 的更多信息，请参阅 PostgreSQL 文档中的[预写日志](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS)。
## 管理 Aurora PostgreSQL 的逻辑插槽
流式传输活动在 `pg_replication_origin_status` 视图中捕获。要查看此视图的内容，您可以使用 `pg_show_replication_origin_status()` 函数，如下所示：
```
SELECT * FROM pg_show_replication_origin_status();
```
您可以使用以下 SQL 查询获取逻辑插槽的列表。
```
SELECT * FROM pg_replication_slots;
```
要删除逻辑插槽，请使用 `pg_drop_replication_slot` 以及插槽的名称，如以下命令所示。
```
SELECT pg_drop_replication_slot('test_slot');
```
# 示例：将逻辑复制与 Aurora PostgreSQL 数据库集群结合使用
以下过程说明了如何在两个 Aurora PostgreSQL 数据库集群之间启动逻辑复制。发布者和订阅者都必须配置为进行逻辑复制，如[为 Aurora PostgreSQL 数据库集群设置逻辑复制](AuroraPostgreSQL.Replication.Logical.Configure.md)中详述。
作为指定发布者的 Aurora PostgreSQL 数据库集群也必须允许访问复制插槽。为此，请基于 Amazon VPC 服务修改与 Aurora PostgreSQL 数据库集群的虚拟公有云（VPC）关联的安全组。通过将与订阅者的 VPC 关联的安全组添加到发布者的安全组来允许入站访问。有关安全组的更多信息，请参阅《Amazon VPC 用户指南》**中的[使用安全组控制到资源的流量](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)。
完成这些初步步骤后，您可以对发布者使用 PostgreSQL 命令 `CREATE PUBLICATION`，并对订阅者使用 PostgreSQL 命令 `CREATE SUBSCRIPTION`，详见以下过程。
**在两个 Aurora PostgreSQL 数据库集群之间启动逻辑复制过程**
这些步骤假设您的 Aurora PostgreSQL 数据库集群有一个写入器实例，其中包含一个用于创建示例表的数据库。
1. **在发布者 Aurora PostgreSQL 数据库集群上**
1. 使用以下 SQL 语句创建一个表。
```
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
```
1. 使用以下 SQL 语句将数据插入到发布者数据库。
```
INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));
```
1. 使用以下 SQL 语句验证表中是否存在数据。
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. 使用 `CREATE PUBLICATION` 语句为此表创建发布，如下所示。
```
CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;
```
1. **在订阅者 Aurora PostgreSQL 数据库集群上**
1. 在订阅者上创建与在发布者上创建的同一个 `LogicalReplicationTest` 表，如下所示。
```
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
```
1. 验证此表为空。
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. 创建订阅以获取来自发布者的更改。您需要使用以下有关发布者 Aurora PostgreSQL 数据库集群的详细信息。
+ **host** – 发布者 Aurora PostgreSQL 数据库集群的写入器数据库实例。
+ **port** – 写入器数据库实例正在侦听的端口。PostgreSQL 的默认值为 5432。
+ **dbname** – 数据库的名称。
```
CREATE SUBSCRIPTION testsub CONNECTION
'host=publisher-cluster-writer-endpoint port=5432 dbname=db-name user=user password=password'
PUBLICATION testpub;
```
**注意**
作为安全最佳实践，请指定除此处所示提示以外的密码。
创建订阅后，将在发布者上创建逻辑复制槽。
1. 要验证此示例中的初始数据是否在订阅者上复制，请在订阅者数据库中使用以下 SQL 语句。
```
SELECT count(*) FROM LogicalReplicationTest;
```
在发布者上进行的任何其他更改都会被复制到订阅者。
逻辑复制会影响性能。我们建议您在复制任务完成后关闭逻辑复制。
# 示例：使用 Aurora PostgreSQL 和 AWS Database Migration Service 的逻辑复制
您可以使用 AWS Database Migration Service (AWS DMS) 复制数据库或数据库的一部分。使用 AWS DMS 将数据从 Aurora PostgreSQL 数据库迁移到另一个开源或商用数据库。有关 AWS DMS 的更多信息，请参阅 [AWS Database Migration Service 用户指南](https://docs.aws.amazon.com/dms/latest/userguide/)。
以下示例演示如何从作为发布者的 Aurora PostgreSQL 数据库设置逻辑复制，然后使用 AWS DMS 进行迁移。此示例使用在 [示例：将逻辑复制与 Aurora PostgreSQL 数据库集群结合使用](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md) 中创建的相同发布者和订阅者。
要设置 AWS DMS 的逻辑复制，需要有您在 Amazon RDS 中的发布者和订阅者的详细信息。特别是，您需要有发布者的写入器数据库实例和订阅者的数据库实例的详细信息。
请获取发布者的写入器数据库实例的以下信息：
+ Virtual Private Cloud (VPC) 标识符
+ 子网组
+ 可用区 (AZ)
+ VPC 安全组
+ 数据库实例 ID
请获取发布者的数据库实例的以下信息：
+ 数据库实例 ID
+ 源引擎
**使用 AWS DMS 进行 Aurora PostgreSQL 的逻辑复制**
1. 准备发布者数据库来与 AWS DMS 一起工作。
要实现此目的，PostgreSQL 10.x 及更高版本的数据库需要您对发布者数据库应用 AWS DMS 封装函数。有关此步骤以及后续步骤的详细信息，请参阅《AWS Database Migration Service 用户指南》**的[将 PostgreSQL 版本 10.x 及更高版本用作 AWS DMS 的源](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10)中的说明。
1. 通过以下网址登录 AWS 管理控制台并打开 AWS DMS 控制台：[https://console.aws.amazon.com/dms/v2](https://console.aws.amazon.com/dms/v2)。在右上方，选择发布者和订阅者所位于的相同 AWS 区域。
1. 创建 AWS DMS 复制实例。
选择与发布者的写入器数据库实例的值相同的值。包括以下设置：
+ 对于 **VPC**，选择与写入器数据库实例相同的 VPC。
+ 对于 **Replication Subnet Group**（复制子网组），选择与写入器数据库实例具有相同值的子网组。如有必要，请创建一个新的子网组。
+ 对于 **Availability zone (可用区)**，选择与写入器数据库实例相同的区域。
+ 对于 **VPC Security Group (VPC 安全组)**，选择与写入器数据库实例相同的组。
1. 为源创建 AWS DMS 终端节点。
使用以下设置将发布者指定为源终端节点：
+ 对于 **Endpoint type (终端节点类型)**，选择 **Source endpoint (源终端节点)**。
+ 选择 **Select RDS DB Instance (选择 RDS 数据库实例)**。
+ 对于 **RDS Instance (RDS 实例)**，选择发布者的写入器数据库实例的数据库标识符。
+ 对于 **Source engine (源引擎)**，选择 **postgres**。
1. 为目标创建 AWS DMS 终端节点。
使用以下设置将订阅者指定为目标终端节点：
+ 对于 **Endpoint type (终端节点类型)**，选择 **Target endpoint (目标终端节点)**。
+ 选择 **Select RDS DB Instance (选择 RDS 数据库实例)**。
+ 对于 **RDS Instance (RDS 实例)**，选择订阅者数据库实例的数据库标识符。
+ 为 **Source engine (源引擎)** 选择值。例如，如果订阅者是 RDS PostgreSQL 数据库，则选择 **postgres**。如果订阅者是 Aurora PostgreSQL 数据库，请选择 **aurora-postgresql**。
1. 创建 AWS DMS 数据库迁移任务。
您使用数据库迁移任务指定要迁移的数据库表，使用目标架构映射数据并在目标数据库上创建新表。至少为 **Task configuration (任务配置)** 使用以下设置：
+ 对于 **Replication instance (复制实例)**，选择您在之前的步骤中创建的复制实例。
+ 对于 **Source database endpoint (源数据库终端节点)**，选择您在之前的步骤中创建的发布者源。
+ 对于 **Target database endpoint (目标数据库终端节点)**，选择您在之前的步骤中创建的订阅者目标。
其余任务详细信息取决于您的迁移项目。有关为 DMS 任务指定所有详细信息的更多信息，请参阅 *AWS Database Migration Service 用户指南*中的[使用 AWS DMS 任务](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.html)。
在 AWS DMS 创建任务后，它开始将数据从发布者迁移到订阅者。
# 为逻辑复制连接配置 IAM 身份验证
从 Aurora PostgreSQL 版本 11 及更高版本开始，您可以对复制连接使用 AWS Identity and Access Management（IAM）身份验证。此功能允许您使用 IAM 角色而不是密码来管理数据库访问权限，从而增强安全性。它在集群级别运行，遵循与标准 IAM 身份验证相同的安全模型。
复制连接的 IAM 身份验证是一项可选功能。要启用 IAM 身份验证，请在数据库集群参数组中将 `rds.iam_auth_for_replication` 参数设置为 `1`。由于这是一个动态参数，因此您的数据库集群无需重新启动，这样您就可以在不停机的情况下对现有工作负载使用 IAM 身份验证。启用此功能之前，您必须满足下面列出的[先决条件](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites)。
## 先决条件
要对复制连接使用 IAM 身份验证，您需要满足以下所有要求：
+ 您的 Aurora PostgreSQL 数据库集群必须为 11 或更高版本。
+ 在发布者 Aurora PostgreSQL 数据库集群上：
+ 启用 IAM 数据库身份验证。
有关更多信息，请参阅 [启用和禁用 IAM 数据库身份验证](UsingWithRDS.IAMDBAuth.Enabling.md)。
+ 通过将 `rds.logical_replication` 参数设置为 `1`，启用逻辑复制。
有关更多信息，请参阅 [为 Aurora PostgreSQL 数据库集群设置逻辑复制](AuroraPostgreSQL.Replication.Logical.Configure.md)。
在逻辑复制中，发布者是向订阅者集群发送数据的源 Aurora PostgreSQL 数据库集群。有关更多信息，请参阅 [Overview of PostgreSQL logical replication with Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.Logical.html)。
**注意**
必须在您的发布者 Aurora PostgreSQL 数据库集群上同时启用 IAM 身份验证和逻辑复制。如果任一项未启用，则无法对复制连接使用 IAM 身份验证。
## 对复制连接启用 IAM 身份验证
要对复制连接启用 IAM 身份验证，请完成以下步骤。
1. 确认您的 Aurora PostgreSQL 数据库集群满足对复制连接使用 IAM 身份验证的所有前提条件。有关更多信息，请参阅 [先决条件](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites)。
1. 要配置 `rds.iam_auth_for_replication` 参数，请修改数据库集群参数组：
+ 将 `rds.iam_auth_for_replication` 参数设置为 `1`。此动态参数不要求重启。
1. 连接到您的数据库并向您的复制用户授予必要的角色：
以下 SQL 命令授予对复制连接启用 IAM 身份验证所需的角色：
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
完成这些步骤后，指定的用户必须对复制连接使用 IAM 身份验证。
**重要**
启用该功能后，同时拥有 `rds_iam` 和 `rds_replication` 角色的用户必须对复制连接使用 IAM 身份验证。无论角色是直接分配给用户还是通过其他角色继承，都是如此。
## 对复制连接禁用 IAM 身份验证
您可以使用下面任何方法对复制连接禁用 IAM 身份验证：
+ 在数据库集群参数组中将 `rds.iam_auth_for_replication` 参数设置为 `0`
+ 或者，您可以在 Aurora PostgreSQL 数据库集群上禁用以下任一功能：
+ 通过将 `rds.logical_replication` 参数设置为 `0`，禁用逻辑复制
+ 禁用 IAM 身份验证
禁用该功能后，复制连接可以使用数据库密码进行身份验证（如果已配置）。
**注意**
即使启用了该功能，没有 `rds_iam` 角色的用户的复制连接也可以使用密码身份验证。
## 限制和注意事项
对复制连接使用 IAM 身份验证时，需遵守以下限制和注意事项。
+ 复制连接的 IAM 身份验证仅适用于 Aurora PostgreSQL 11 及更高版本。
+ 发布者必须支持对复制连接使用 IAM 身份验证。
+ 默认情况下，IAM 身份验证令牌会在 15 分钟后失效。在令牌失效之前，您可能需要刷新长时间运行的复制连接。