我在 AWS RDS 上有两个 Postgres 13 数据库。
- 一个是主服务器，另一个是使用逻辑复制的从服务器。
- 复制已落后约350Gb。
- 过去四天里，由于一些正在进行的工作，从属服务器的 CPU 已经达到最大限度，所以我不确定在此期间逻辑复制能够复制什么。
- 我终止了这些作业，现在主服务器和从服务器的 CPU 都很低。
- 我查看了订阅者
select * from pg_stat_subscription;，发现虽然latest_end_lsn进展很慢，但还是在进步。 - 出版商说写入/刷新/重放延迟都落后了 13 分钟，但一天中的大部分时间都是这样的。
- 除了用户犯的一些简单的 SQL 错误之外，我没有在发布者或订阅者的日志中看到任何错误。
我能做些什么吗？之前我将wal_receiver_timeout超时设置为 0，因为我遇到了复制问题，这很有帮助。我希望我能在这里有一些可见性，以便确信它会成功，但除了这些lsn值和数据库日志之外，我不确定要检查什么。
我弄清楚了我的问题是什么：订阅者的触发器。
我看到
pg_locks一个表不断被访问。表上有排他锁，没有其他查询想要使用它，这很好。它一直很忙。我不知怎么找到了
pg_stat_user_functions一个函数（比如触发器函数）执行时间的数值。有一对函数的运行时间非常长，而且时间还在不断增加。我做了一个
alter table foo disable trigger x，完成后，复制立即开始流动。我的数据现在已经过时了，因为触发器没有运行，但只要我的发布者没有因为空间不足而崩溃，那就没问题了。复制完成后，我重新启用了触发器，一切运行正常。