如何对 Aurora PostgreSQL 兼容版源数据库集群的逻辑复制问题进行故障排除？

2 分钟阅读

我想对 Amazon Aurora PostgreSQL 兼容版源数据库 (DB) 集群的逻辑复制问题进行故障排除。

解决方法

配置复制参数

在对逻辑复制问题进行故障排除之前，请为数据库集群参数组配置以下参数：

将 rds.logical_replication 值设置为 1，在数据库集群上启用逻辑复制。
为 max_replication_slots 设置一个值，使其包含满足预期订阅数量及额外的表同步进程所需的槽位。
将 max_wal_senders 设置为能够支持 max_replication_slots 配额及当前物理副本的值。
将 max_logical_replication_workers 设置为能够支持订阅数量及复制系统进行表同步所需额外工作线程数的值。
将 max_worker_processes 设置为至少比 max_logical_replication_workers 多一的值。例如，如果 max_logical_replication_workers 为 25，则将 max_worker_processes 设置为 26。
如果数据复制缓慢，则增加 max_sync_workers_per_subscription 值，以便控制处理订阅设置和新增表同步的工作线程数。

**重要事项：**要应用上述更改，必须重启 Aurora PostgreSQL 兼容版数据库集群。

检查发布和订阅配置

配置好逻辑复制参数后，请验证您是否已正确配置发布和订阅。确保发布包含所有预期的表，订阅参数正确无误，且复制用户具有相应的权限。

连接到您的源数据库，然后运行以下命令。

要检查您的发布配置，请运行以下命令：

SELECT * FROM pg_publication;
SELECT * FROM pg_publication_tables;

要检查您的订阅配置，请运行以下命令：

SELECT * FROM pg_subscription;
SELECT * FROM pg_subscription_rel;

确认复制槽处于活动状态

连接到您的源数据库，然后运行以下命令：

SELECT slot_name, plugin, slot_type, active, restart_lsn,
       confirmed_flush_lsn, pg_current_wal_lsn(),
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag
FROM pg_replication_slots;

如果槽位处于非活动状态或显示延迟过高，则检查复制工作线程以排查问题。

确认复制工作线程处于活动状态

连接到您的目标数据库，然后运行以下命令：

SELECT pid, state, query, wait_event, backend_type
FROM pg_stat_activity
WHERE backend_type LIKE 'logical replication%';

如果没有复制工作线程，请重新启动您的订阅。

要关闭您的订阅，请运行以下命令：

ALTER SUBSCRIPTION subscription_name DISABLE;

要开启您的订阅，请运行以下命令：

ALTER SUBSCRIPTION subscription_name ENABLE;

如果重新启动订阅后仍没有复制工作线程，请检查 PostgreSQL 错误日志中是否存在错误消息。

监控复制进度和延迟

由于发布端事务量大或存在大型事务，您的复制可能会出现延迟。或者，发布或订阅可能会受到限制。

要确定复制是已停止还是运行缓慢，请间隔监控复制进度。

连接到您的数据库集群，然后运行以下命令。

要检查发布的复制进度，请运行以下命令：

SELECT slot_name,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag,
       active
FROM pg_replication_slots
WHERE slot_type = 'logical';

要检查订阅的复制进度，请运行以下命令：

SELECT subname, pid, received_lsn, latest_end_lsn,
       pg_size_pretty(pg_wal_lsn_diff(latest_end_lsn, received_lsn)) AS lag
FROM pg_stat_subscription;

为了最大限度地减少复制延迟，请监控直写缓存。如果缓存大小不足以容纳您的工作负载，则可以手动更改 rds.logical_wal_cache 的值。有关更多信息，请参阅借助适用于 Aurora PostgreSQL 的最新直写缓存，将复制延迟降低多达 17 倍。

监控资源限制

要排查发布者和订阅用户的资源限制问题，请启用增强监控并监控 CPUUtilization、FreeableMemory、SwapUsage 和 NetworkThroughput。设置 Amazon CloudWatch 警报，以便在出现复制问题时收到通知。

有关详细信息，请参阅如何确定我的 Amazon RDS for PostgreSQL 或 Aurora PostgreSQL 兼容版数据库实例中的性能问题和运行缓慢的查询并对其进行故障排除？

识别架构不匹配并解决数据不一致问题

连接到您的源数据库和目标数据库。然后，确认已复制表中的列以及数据类型是否兼容。此外，请确保主键和唯一约束保持一致。

要开启您的订阅，请运行以下命令：

ALTER SUBSCRIPTION subscription_name ENABLE;

要比较表定义，请在两个数据库上运行以下命令：

SELECT column_name, data_type, character_maximum_length
FROM information_schema.columns
WHERE table_name = 'your_table_name'
ORDER BY ordinal_position;

**注意：**请将 your_table_name 替换为您的表名。

解决冲突

原生 PostgreSQL 逻辑复制无法检测来自多个发布者的数据冲突，也无法检测与您在本地更改的数据相冲突的复制修改。如果当前行具有相同的键，则 Aurora 会应用更新，插入操作将失败。

要确定导致冲突的原因，请检查 PostgreSQL 日志。

以下示例日志显示，之所以复制失败，是由于尝试插入记录的资产 ID 在目标数据库中已存在：

ERROR: 23505: duplicate key value violates unique constraint "asset_pkey"
DETAIL: Key (asset_id)=(7) already exists.
CONTEXT: processing remote data for replication origin "pg_32796" during message type "INSERT" for replication target relation "public.asset" in transaction 315434, finished at 0/6A12458

复制源为 pg_32796，以逻辑序列号 (LSN) 0/6A12458 结束。

要手动修复数据，可以在冲突时停止复制，也可以使用 disable_on_error 选项配置订阅。

或者，您可以检查源和目标上的数据，确定是否可以跳过导致冲突的 LSN。然后，使用 pg_replication_origin_advance() 函数跳过导致冲突的 LSN。有关更多信息，请参阅 PostgreSQL 网站上的 pg_replication_origin_advance (node_name text, lsn pg_lsn)。

**注意：**Aurora PostgreSQL 兼容版本 15 及更高版本支持 pg_replication_origin_advance() 函数。

要跳过 LSN，请完成以下步骤：

运行以下 SQL 命令以暂时关闭订阅：
```
ALTER SUBSCRIPTION subscription_name DISABLE;
```
**注意：**如果您使用 disable_on_error 选项配置了订阅，则订阅会在出现错误后自动关闭。

使用以下 pg_replication_origin_advance() 函数将源推进至 Finish_LSN+1：

SELECT pg_replication_origin_advance('node_name','Finish_LSN+1'::pg_lsn);

**注意：**请将 node_name 替换为您的节点名称。

运行以下命令以关闭订阅：

ALTER SUBSCRIPTION subscription-name ENABLE;

**注意：**请将 subscription-name 替换为您的订阅名称。

要解决多个数据不一致问题，您可能需要清理目标表并重新配置发布和订阅。