Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

使用扩展和外部数据包装器

要扩展 Aurora PostgreSQL 兼容版数据库集群的功能，您可以安装和使用各种 PostgreSQL 扩展。例如，如果您的使用案例要求在非常大的表中输入密集型数据，则可以安装 pg_partman 扩展以对数据进行分区，从而分散工作负载。

在某些情况下，您可以将特定模块添加到 Aurora PostgreSQL 数据库集群的自定义数据库集群参数组中的 shared_preload_libraries 列表中，而不是安装扩展。通常，原定设置的数据库集群参数组仅加载 pg_stat_statements，但还有其他几个模块可供添加到此列表中。例如，您可以通过添加 pg_cron 模块来添加调度功能，详情请见使用 PostgreSQL pg_cron 扩展计划维护。再举一个例子，您可以通过加载 auto_explain 模块来记录查询执行计划。要了解更多信息，请参阅 Amazon 知识中心中的记录查询执行计划。

提供对外部数据的访问权限的扩展更具体地称为外部数据包装器（FDW）。例如，oracle_fdw 扩展允许 Aurora PostgreSQL 数据库集群使用 Oracle 数据库。

接下来，您可以找到有关设置和使用 Aurora PostgreSQL 可用的一些扩展、模块和 FDW 的信息。为简单起见，这些都称为“扩展”。您可以找到可与当前可用的 Aurora PostgreSQL 版本结合使用的扩展列表，请参阅《Aurora PostgreSQL 版本注释》中的 Amazon Aurora PostgreSQL 的扩展版本。

使用 pgAudit 记录数据库活动

金融机构、政府机构和许多行业需要保留审计日志以满足监管要求。通过将 PostgreSQL Audit 扩展（pgAudit）与 Aurora PostgreSQL 数据库集群结合使用，您可以捕获审计人员通常需要或满足监管要求的详细记录。例如，您可以设置 pgAudit 扩展来跟踪对特定数据库和表所做的更改，记录进行更改的用户以及许多其他详细信息。

pgAudit 扩展通过更详细地扩展日志消息，进一步构建原生 PostgreSQL 日志记录基础设施的功能。换句话说，您将使用与查看任何日志消息相同的方法来查看审计日志。有关 PostgreSQL 日志记录的更多信息，请参阅 Aurora PostgreSQL 数据库日志文件。

pgAudit 扩展会编辑日志中的敏感数据，例如明文密码。如果您的 Aurora PostgreSQL 数据库集群配置为记录数据操作语言（DML）语句（详情请见为您的 Aurora PostgreSQL 数据库集群开启查询日志记录），则可以使用 PostgreSQL Audit 扩展来避免明文密码问题。

您可以在数据库实例上配置具有高度明确性的审计。您可以审计所有数据库和所有用户。或者，您可以选择仅审计某些数据库、用户和其他对象。您也可以明确排除对某些用户和数据库进行审计。有关更多信息，请参阅从审计日志记录中排除用户或数据库。

考虑到可以捕获的详细信息量，我们建议您在使用 pgAudit 时监控存储消耗。

所有可用的 Aurora PostgreSQL 版本都支持 pgAudit 扩展。有关 Aurora PostgreSQL 版本支持的 pgAudit 版本的列表，请参阅《Aurora PostgreSQL 版本注释》https://docs.amazonaws.cn/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html中的 Amazon Aurora PostgreSQL 的扩展版本。。

设置 pgAudit 扩展

要在 Aurora PostgreSQL 数据库集群上设置 pgAudit 扩展，首先要将 pgAudit 添加到 Aurora PostgreSQL 数据库集群的自定义数据库集群参数组上的共享库中。有关创建自定义数据库集群参数组的信息，请参阅使用参数组。接下来，安装 pgAudit 扩展。最后，指定要审计的数据库和对象。本部分中的过程向您展示如何操作。您可以使用 Amazon Web Services Management Console或 Amazon CLI。

您必须拥有 rds_superuser 角色的权限才能执行所有这些任务。

以下步骤假设您的 Aurora PostgreSQL 数据库集群 与自定义数据库集群 参数组相关联。

审计数据库对象

在 Aurora PostgreSQL 数据库集群 上设置 pgAudit 并根据您的要求进行配置后，将在 PostgreSQL 日志中捕获更多详细信息。例如，虽然原定设置 PostgreSQL 日志记录配置标识数据库表中发生更改的日期和时间，但使用 pgAudit 扩展后，日志条目可以包括模式、进行更改的用户和其他详细信息，具体取决于扩展参数的配置方式。您可以设置审计以通过以下方法跟踪更改。

当您在系统上创建 rds_pgaudit 角色，然后将此角色添加到自定义参数组中的 pgaudit.role 参数时，将激活对象审计功能。原定设置情况下，pgaudit.role 参数处于未设置状态，唯一允许的值是 rds_pgaudit。以下步骤假设 pgaudit 已初始化，并且您已按照设置 pgAudit 扩展中的步骤创建了 pgaudit 扩展。

如本示例所示，“LOG: AUDIT: SESSION”行提供了有关表及其架构的信息以及其他详细信息。

要测试 pgAudit 日志记录，您可以运行几条要审计的示例命令。例如，您可以运行以下命令。

CREATE TABLE t1 (id int);
GRANT SELECT ON t1 TO rds_pgaudit;
SELECT * FROM t1;
id 
----
(0 rows)

数据库日志应包含类似于以下内容的条目。

...
2017-06-12 19:09:49 UTC:...:rds_test@postgres:[11701]:LOG: AUDIT:
OBJECT,1,1,READ,SELECT,TABLE,public.t1,select * from t1;
...

有关查看日志的信息，请参阅监控 Amazon Aurora 日志文件。

要了解关于 pgAudit 扩展的更多信息，请参阅 GitHub 上的 pgAudit。

从审计日志记录中排除用户或数据库

如 Aurora PostgreSQL 数据库日志文件中所述，PostgreSQL 日志会消耗存储空间。使用 pgAudit 扩展会在不同程度上增加日志中收集的数据量，具体取决于您跟踪的更改。您可能不需要审计 Aurora PostgreSQL 数据库集群 中的每个用户或数据库。

为了最大限度地减少对存储的影响，避免不必要地捕获审计记录，您可以将用户和数据库排除在审计范围之外。您还可以在给定会话中更改日志记录。下面的示例向您演示如何操作。

假设您的 Aurora PostgreSQL 数据库集群 配置为审计所有用户和数据库的相同级别的活动。然后，您决定不想对用户 myuser 进行审计。您可以使用以下 SQL 命令对 myuser 关闭审计功能。

ALTER USER myuser SET pgaudit.log TO 'NONE';

然后，您可以使用以下查询来检查 pgaudit.log 的 user_specific_settings 列，以确认该参数已设置为 NONE。

SELECT
    usename AS user_name,
    useconfig AS user_specific_settings
FROM
    pg_user
WHERE
    usename = 'myuser';

您将看到如下输出。

 user_name | user_specific_settings
-----------+------------------------
 myuser    | {pgaudit.log=NONE}
(1 row)

在给定用户与数据库的会话期间，您可以使用以下命令对此用户关闭日志记录功能。

ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'none';

使用以下查询，对于特定用户和数据库组合检查 pgaudit.log 的设置列。

SELECT
    usename AS "user_name",
    datname AS "database_name",
    pg_catalog.array_to_string(setconfig, E'\n') AS "settings"
FROM
    pg_catalog.pg_db_role_setting s
    LEFT JOIN pg_catalog.pg_database d ON d.oid = setdatabase
    LEFT JOIN pg_catalog.pg_user r ON r.usesysid = setrole
WHERE
    usename = 'myuser'
    AND datname = 'mydatabase'
ORDER BY
    1,
    2;

您将看到类似以下内容的输出。

  user_name | database_name |     settings
-----------+---------------+------------------
 myuser    | mydatabase    | pgaudit.log=none
(1 row)

对 myuser 关闭审计后，您决定不想跟踪对 mydatabase 的更改。您可以使用以下命令对该特定数据库关闭审计。

ALTER DATABASE mydatabase SET pgaudit.log to 'NONE';

然后，使用以下查询检查 database_specific_settings 列，以确认 pgaudit.log 已设置为 NONE。

SELECT
a.datname AS database_name,
b.setconfig AS database_specific_settings
FROM
pg_database a
FULL JOIN pg_db_role_setting b ON a.oid = b.setdatabase
WHERE
a.datname = 'mydatabase';

您将看到如下输出。

 database_name | database_specific_settings
---------------+----------------------------
 mydatabase    | {pgaudit.log=NONE}
(1 row)

要将 myuser 的设置恢复为原定设置，请使用以下命令：

ALTER USER myuser RESET pgaudit.log;

要将数据库的设置恢复为原定设置，请使用以下命令。

ALTER DATABASE mydatabase RESET pgaudit.log;

要将用户和数据库重置为原定设置，请使用以下命令。

ALTER USER myuser IN DATABASE mydatabase RESET pgaudit.log;

还可以通过将 pgaudit.log 设置为 pgaudit.log 参数的其他允许值之一，将特定事件捕获到日志中。有关更多信息，请参阅pgaudit.log 参数允许的设置列表。

ALTER USER myuser SET pgaudit.log TO 'read';
ALTER DATABASE mydatabase SET pgaudit.log TO 'function';
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'read,function'

pgAudit 扩展的参考

您可以通过更改本节中列出的一个或多个参数来为审计日志指定所需的详细级别。

控制 pgAudit 行为

您可以通过更改下表中列出的一个或多个参数来控制审计日志记录。

pgaudit.log 参数允许的设置列表

要使用会话审计记录多种事件类型，请使用逗号分隔的列表。要记录所有事件类型，请将 pgaudit.log 设置为 ALL。重启数据库实例以应用更改。

通过对象审计，您可以细化审计日志记录以使用特定的关系。例如，您可以指定要对一个或多个表上的 READ 操作进行审计日志记录。

使用 pglogical 跨实例同步数据

所有当前可用的 Aurora PostgreSQL 版本都支持 pglogical 扩展。pglogic 扩展早于 PostgreSQL 在版本 10 中引入的功能类似的逻辑复制功能。有关更多信息，请参阅 使用 Aurora 的 PostgreSQL 逻辑复制。

pglogical 扩展支持在两个或更多 Aurora PostgreSQL 数据库集群 之间进行逻辑复制。它还支持在不同的 PostgreSQL 版本之间进行复制，以及在 RDS for PostgreSQL 数据库实例和 Aurora PostgreSQL 数据库集群上运行的数据库之间进行复制。pglogical 扩展使用发布-订阅模型将对表和其他对象（例如序列）的更改从发布者复制到订阅者。它依赖于复制插槽来确保更改从发布者节点同步到订阅者节点，定义如下。

在下文中，您可以了解有关设置 pglogical 扩展的信息。

pglogical 扩展的要求和限制

所有当前可用的 Aurora PostgreSQL 版本都支持 pglogical 扩展。

发布者节点和订阅者节点都必须设置为进行逻辑复制。

要从订阅者复制到发布者的表必须具有相同的名称和相同的模式。这些表还必须包含相同的列，并且这些列必须使用相同的数据类型。发布者表和订阅者表必须具有相同的主键。我们建议您仅使用 PRIMARY KEY 作为唯一约束。

对于 CHECK 约束和 NOT NULL 约束，订阅者节点上的表可能比发布者节点上的表具有更宽松的约束。

pglogical 扩展提供了诸如双向复制之类的功能，PostgreSQL（版本 10 及更高版本）中内置的逻辑复制功能不支持这些功能。有关更多信息，请参阅使用 pglogic 进行 PostgreSQL 双向复制。

设置 pglogical 扩展

要在 Aurora PostgreSQL 数据库集群上设置 pglogical 扩展，首先要将 pglogical 添加到 Aurora PostgreSQL 数据库集群的自定义数据库集群参数组上的共享库中。您还需要将 rds.logical_replication 参数的值设置为 1，以开启逻辑解码。最后，在数据库中创建此扩展。您可以使用 Amazon Web Services Management Console或 Amazon CLI 执行这些任务。

您必须拥有 rds_superuser 角色的权限才能执行这些任务。

以下步骤假设您的 Aurora PostgreSQL 数据库集群 与自定义数据库集群 参数组相关联。有关创建自定义数据库集群参数组的信息，请参阅使用参数组。

为 Aurora PostgreSQL 数据库集群设置逻辑复制

以下过程说明如何在两个 Aurora PostgreSQL 数据库集群之间启动逻辑复制。这些步骤假设来源（发布者）和目标（订阅者）都如 设置 pglogical 扩展 中所述设置了 pglogical 扩展。

发布者节点设置已完成。现在，您可以设置订阅者节点以接收来自发布者的更新。

此后，对发布者上的表所做的更改将复制到订阅者上的表中。

在主要升级后重新建立逻辑复制

对于设置为逻辑复制的发布者节点的 Aurora PostgreSQL 数据库集群，在可以对其执行主要版本升级之前，您必须删除所有复制插槽，即使是不活动的复制插槽也是如此。我们建议您暂时从发布者节点转移数据库事务，删除复制插槽，升级 Aurora PostgreSQL 数据库集群，然后重新建立并重新启动复制。

复制插槽仅托管在发布者节点上。逻辑复制场景中的 Aurora PostgreSQL 订阅者节点没有要删除的插槽。Aurora PostgreSQL 主要版本升级过程支持将订阅者升级到独立于发布者节点的 PostgreSQL 的新主要版本。但是，升级过程确实会中断复制过程并干扰发布者节点和订阅者节点之间的 WAL 数据同步。在升级发布者、订阅者或两者之后，您需要在发布者和订阅者之间重新建立逻辑复制。以下过程说明了如何确定复制已中断以及如何解决此问题。

确定逻辑复制已中断

您可以通过查询发布者节点或订阅者节点来确定复制过程是否已中断，如下所示。

如果您的逻辑复制过程已中断，则可以按照以下步骤重新建立复制。

检查节点的状态。其状态应为 replicating，如本例所示。

SELECT subscription_name,status,slot_name
  FROM pglogical.show_subscription_status();
             subscription_name |   status    |              slot_name
-------------------------------+-------------+-------------------------------------
 docs_lab_subscription         | replicating | pgl_labdb_docs_lab98f517b_docs_lab3de412c
(1 row)

检查发布者节点上订阅者的复制插槽的状态。插槽的 active 列应返回 t（true），表示已重新建立复制。

SELECT slot_name,plugin,slot_type,active
  FROM pg_replication_slots;
                    slot_name              |      plugin      | slot_type | active
-------------------------------------------+------------------+-----------+--------
 pgl_labdb_docs_lab98f517b_docs_lab3de412c | pglogical_output | logical   | t
(1 row)

管理 Aurora PostgreSQL 的逻辑复制查槽

对于在逻辑复制场景中充当发布者节点的 Aurora PostgreSQL 数据库集群的编写器实例，在对其执行主要版本升级之前，必须删除该实例上的复制插槽。主要版本升级预检查过程会通知您，在插槽被删除之前，升级无法继续。

要识别使用 pglogical 扩展创建的复制插槽，请登录到每个数据库并获取节点的名称。当您查询订阅者节点时，您会在输出中得到发布者节点和订阅者节点，如本示例所示。

SELECT * FROM pglogical.node;
node_id   |     node_name
------------+-------------------
 2182738256 | docs_lab_target
 3410995529 | docs_lab_provider
(2 rows)

您可以通过以下查询获取有关订阅的详细信息。

SELECT sub_name,sub_slot_name,sub_target
  FROM pglogical.subscription;
 sub_name |         sub_slot_name          | sub_target
----------+--------------------------------+------------
  docs_lab_subscription     | pgl_labdb_docs_labcb4fa94_docs_lab3de412c | 2182738256
(1 row)

现在您可以删除订阅，如下所示。

SELECT pglogical.drop_subscription(subscription_name := 'docs_lab_subscription');
 drop_subscription
-------------------
                 1
(1 row)

删除订阅后，您可以删除该节点。

SELECT pglogical.drop_node(node_name := 'docs-lab-subscriber');
 drop_node
-----------
 t
(1 row)

您可以验证该节点是否不再存在，如下所示。

SELECT * FROM pglogical.node;
 node_id | node_name
---------+-----------
(0 rows)

pglogical 扩展的参数参考

在表中，您可以找到与 pglogical 扩展关联的参数。pglogical.conflict_log_level 和 pglogical.conflict_resolution 等参数用于处理更新冲突。当对订阅来自发布者的更改的相同表进行本地更改时，可能会出现冲突。在不同情况下也可能发生冲突，例如双向复制或当多个订阅者从同一个发布者进行复制时。有关更多信息，请参阅使用 pglogical 进行 PostgreSQL 双向复制。