PostgreSQL 集群异常恢复
内容提要
该文章讨论Patroni+PostgreSQL集群中备库节点启动卡住的问题。故障因节点数据停留在旧Timeline 8，而主库已到Timeline 266，导致WAL回放缓慢，数据库拒绝连接。建议先检查PG日志和进程，若恢复无进展，推荐停止Patroni、清空数据目录，再重启以触发从主库重新克隆，快速恢复集群一致性。
延伸解读
跨Timeline恢复为何会卡住
备库数据停留在Timeline 8，而主库已推进到Timeline 266，跨度极大。PostgreSQL备库启动时必须先回放本地WAL直至追上当前时间线，期间会拒绝连接。由于需要跨越大量历史记录，回放可能极其缓慢甚至看似卡死，这是导致节点长时间处于starting状态的根本原因。
重建副本的适用场景
当备库因落后过多而恢复无进展时，清空数据目录并让Patroni重新克隆是推荐做法。此操作会触发pg_basebackup从主库全量同步，快速恢复一致性。但需注意，仅适用于确认数据无新增写入且Patroni可正常管理的情况，操作前务必核对数据目录路径，避免误删。
排查顺序与关键信号
排查时应先查看PostgreSQL原生日志，确认是否在持续redo及有无报错；再检查进程状态和端口监听。若日志显示redo进度停滞或出现PANIC，则考虑重建。若日志中LSN持续增长，说明恢复仍在进行，可暂不干预。网络连通性也需验证，确保备库能访问主库。
Q&A
Patroni+PostgreSQL集群中备库节点一直处于starting状态且Lag in MB显示unknown，可能是什么原因？
备库节点一直处于starting状态且Lag in MB显示unknown，通常是因为PostgreSQL进程正在进行WAL日志回放（崩溃恢复或备库恢复），尚未达到一致性状态，因此拒绝连接。Patroni无法连接到数据库查询复制延迟，所以显示starting和unknown。常见原因是备库数据停留在旧Timeline，而主库已切换到新Timeline，导致需要回放大量WAL日志，恢复过程漫长。
PostgreSQL备库启动时卡在恢复阶段，如何通过日志判断是否在正常回放WAL？
可以通过查看PostgreSQL原生日志来判断。关注日志中的关键词：如果看到'redo starts at ...'且LSN不断前进，说明正在正常回放；如果长时间卡在'redo starts'没有进度，或出现'FATAL'、'PANIC'等错误，则可能有问题。另外，如果日志显示'waiting for WAL to become available'，可能无法连接到主库获取WAL。
Patroni集群中备库数据落后太多（如Timeline从8到266），直接清空数据目录重建副本是否安全？
安全。在Patroni集群中，清空故障节点的数据目录并重启Patroni，会触发自动克隆（pg_basebackup）从当前主库重新同步数据，这是官方推荐的标准做法。操作前需停止Patroni，确认数据目录路径无误后清空内容，再启动Patroni即可。
Patroni集群中备库节点启动卡住，有哪些排查步骤？
排查步骤包括：1. 检查PostgreSQL原生日志，关注redo、错误等信息；2. 检查进程状态，确认PG进程是否存在及状态；3. 手动尝试连接数据库，查看具体报错；4. 检查网络连通性，确保能访问主库的5432端口。
Patroni集群中备库节点数据目录被清空后，如何触发重新克隆？
清空数据目录后，启动Patroni服务，Patroni检测到数据目录为空，会自动触发pg_basebackup从当前主库克隆数据。可以通过查看Patroni日志或使用patronictl list观察状态变化，从starting变为running，Lag in MB从unknown变为具体数值并逐渐减小。
Patroni集群中备库节点启动时显示'FATAL: the database system is starting up'，是什么意思？
该错误表示PostgreSQL进程已经启动，但正在进行崩溃恢复或WAL回放，尚未达到一致性状态，因此拒绝所有连接。这是备库启动过程中的正常现象，但如果长时间不结束，可能意味着恢复卡住或数据落后太多。
Patroni集群中备库节点数据落后太多，是等待其自行追平还是重建副本？
如果备库数据落后太多（如Timeline差距巨大），等待其自行追平可能非常耗时且容易出错，推荐直接重建副本。清空数据目录让Patroni重新克隆是解决此问题的最佳实践，可以快速恢复集群一致性。
