PostgreSQL 逻辑复制故障排除实战：pg_stat_replication 与 pg_stat_subscription 视图深度解析

大家好，我是你们的老朋友，码农老王。

PostgreSQL 的逻辑复制功能为我们提供了灵活的数据同步方案，但在实际生产环境中，难免会遇到各种各样的故障。今天，咱们就来聊聊如何利用 pg_stat_replication 和 pg_stat_subscription 这两个强大的视图，结合具体的故障案例，进行深入的故障诊断和恢复。别担心，我会尽量用大白话，结合实际操作，让大家都能听得懂，学得会。

逻辑复制基础回顾

在深入故障排除之前，咱们先简单回顾一下 PostgreSQL 逻辑复制的基本概念。逻辑复制基于发布/订阅模型，允许我们将一个数据库（发布者）中的数据变更实时同步到一个或多个数据库（订阅者）。

• 发布者 (Publisher)：数据源，负责将数据变更以逻辑复制流的形式发送给订阅者。
• 订阅者 (Subscriber)：数据接收方，负责接收并应用来自发布者的变更。
• 发布 (Publication)：定义了发布者上哪些表的数据需要被复制。
• 订阅 (Subscription)：定义了订阅者如何连接到发布者，以及接收哪些发布。

关键视图：pg_stat_replication 和 pg_stat_subscription

这两个视图是咱们进行逻辑复制故障排除的“左膀右臂”。

pg_stat_replication

这个视图提供了发布者上关于复制槽和连接的详细信息。通过它，我们可以了解：

• 有哪些订阅者连接到了发布者？
• 复制的延迟情况如何？
• 复制槽的状态是否正常？

来，咱们看几个关键的字段：

• pid：Walsender 进程的 PID，可以用来跟踪具体的复制进程。
• state：Walsender 进程的状态，常见的有 startup、catchup、streaming、backup、stopping。
• sent_lsn：发布者已经发送的最后一个 WAL 日志位置。
• write_lsn：订阅者已经写入磁盘的最后一个 WAL 日志位置。
• flush_lsn：订阅者已经刷新到磁盘的最后一个 WAL 日志位置。
• replay_lsn：订阅者已经应用的最后一个 WAL 日志位置。
• write_lag、flush_lag、replay_lag：分别表示写入、刷新和应用的延迟时间。

pg_stat_subscription

这个视图提供了订阅者上关于订阅的详细信息。通过它，我们可以了解：

• 订阅的状态是否正常？
• 订阅接收和应用数据的延迟情况如何？

关键字段包括：

• subid：订阅的 OID。
• subname：订阅的名称。
• pid：Apply worker 进程的 PID。
• received_lsn：订阅者接收到的最后一个 WAL 日志位置。
• last_msg_send_time：订阅者接收到最后一条消息的时间。
• last_msg_receipt_time：订阅者处理最后一条消息的时间。
• latest_end_lsn：订阅者应用完成的最后一个事务的 LSN。
• latest_end_time：订阅者应用完成最后一个事务的时间。

故障案例分析与解决

接下来，咱们结合几个常见的故障案例，看看如何利用这两个视图进行故障排除。

案例一：网络中断导致复制延迟

现象：订阅者上的数据明显落后于发布者，pg_stat_replication 视图中 write_lag、flush_lag、replay_lag 持续增大。

排查步骤：

1. 在发布者上查看 pg_stat_replication：

   SELECT * FROM pg_stat_replication;
   

   观察 state 字段，如果一直是 streaming，但 write_lag 等持续增大，很可能是网络问题。

2. 检查发布者和订阅者之间的网络连接：

   ping <订阅者IP>
   traceroute <订阅者IP>

   确认网络是否畅通，是否有丢包或延迟过高的情况。

3. 在订阅者上查看 pg_stat_subscription：

   SELECT * FROM pg_stat_subscription;
   

   观察 received_lsn 和 latest_end_lsn，如果 received_lsn 增长缓慢或停滞，进一步确认是网络问题。

解决方案：

• 修复网络问题，确保发布者和订阅者之间的网络连接稳定。
• 如果网络暂时无法恢复，可以考虑暂停订阅，待网络恢复后再重新启用。
• 如果数据差异过大，可能需要重新初始化订阅。

案例二：订阅者宕机

现象：订阅者服务停止，pg_stat_replication 视图中对应的连接消失。

排查步骤：

1. 在发布者上查看 pg_stat_replication，确认没有对应的订阅者连接。
2. 尝试连接订阅者数据库，确认服务是否正常。

解决方案：

• 重启订阅者服务。
• 如果订阅者无法启动，检查错误日志，排除故障原因。
• 如果数据差异过大，可能需要重新初始化订阅。

案例三：发布者磁盘空间不足

现象：发布者磁盘空间告警，复制延迟增加。

排查步骤：

1. 在发布者上查看磁盘空间使用情况：

   df -h
   

2. 检查 PostgreSQL 数据目录的磁盘空间。

3. 查看 pg_stat_replication，确认是否有大量的 WAL 日志堆积。

解决方案：

• 清理发布者磁盘空间，删除不必要的文件。
• 如果 WAL 日志过多，可以考虑调整 WAL 归档策略，或者增加磁盘空间。
• 如果是因为某个订阅者长时间未同步导致 WAL 堆积，可以考虑删除该订阅，或者强制同步。

案例四：订阅者 Apply Worker 进程错误

现象：pg_stat_subscription 视图中，pid 字段对应的 Apply Worker 进程不存在，或者状态异常。

排查步骤：

1. 在订阅者上查看 pg_stat_subscription：

   SELECT * FROM pg_stat_subscription;
   

   观察pid，last_msg_receipt_time,latest_end_time等信息.

2. 检查订阅者的错误日志，查找 Apply Worker 进程的错误信息。

解决方案：

• 根据错误日志中的信息，修复导致 Apply Worker 进程退出的问题。
• 重启订阅，Apply Worker 进程会自动重新启动。
• 如果问题无法解决，可能需要重建订阅。

案例五：复制槽（Replication Slot）异常

现象：复制延迟持续增加，pg_stat_replication 视图中 active 字段为 f，或者 restart_lsn 远远落后于 sent_lsn。

排查步骤：

1. 在发布者上查看 pg_stat_replication：

    SELECT slot_name, active, restart_lsn, sent_lsn FROM pg_stat_replication;
   

2. 检查复制槽的状态是否正常。

解决方案：

• 如果复制槽处于非活动状态（active=f），尝试重新启动订阅。
• 如果 restart_lsn 远远落后于 sent_lsn，说明复制槽可能已经损坏，可以考虑删除并重建复制槽。
• 在删除复制槽之前，请务必确保没有其他订阅者在使用该复制槽，否则可能导致数据丢失。

总结与建议

通过以上案例，相信大家对如何利用 pg_stat_replication 和 pg_stat_subscription 进行逻辑复制故障排除有了一定的了解。在实际工作中，我们还需要结合具体的环境和日志信息，进行综合分析。

最后，给大家几点建议：

• 定期监控：建立完善的监控体系，定期检查复制状态，及时发现并解决问题。
• 日志分析：养成查看日志的习惯，日志中包含了大量有用的信息。
• 备份恢复：做好数据备份，以防万一。
• 多加练习：在测试环境中模拟各种故障场景，熟悉故障排除流程。

希望今天的分享对大家有所帮助。如果你在实际工作中遇到了其他逻辑复制相关的问题，欢迎在评论区留言，咱们一起探讨，共同进步！