调整wal_receiver_timeout与wal_sender_timeout对异步流物理复制的影响及RPO变化

先明确两个参数的核心作用：

• wal_sender_timeout：主库端的WAL发送进程，若超过设定时间未收到备库的反馈（心跳或确认），会主动断开复制连接
• wal_receiver_timeout：备库端的WAL接收进程，若超过设定时间未收到主库的WAL数据或心跳包，会断开连接并尝试重连

默认1分钟的超时是为了快速检测复制链路异常，调整到60分钟后会带来以下潜在影响：

潜在影响 #

• 故障检测延迟显著增加：无论是主库宕机、网络中断还是备库异常，原本1分钟内就能触发的故障检测，现在要等60分钟才会触发。这期间备库会停滞在断连前的状态，不会尝试重连，也无法获取新的WAL数据。
• 临时网络波动的容忍性提升：如果只是几分钟的网络抖动或短时中断，原本会触发复制断开和重连流程，现在不会中断复制，减少了不必要的重连开销和复制中断次数，适合网络整体稳定但偶有小波动的场景。
• 主库资源占用风险：若备库因磁盘IO挂起、进程卡住等原因无法响应主库，主库的WAL发送进程会一直保留连接，直到60分钟超时后才会释放。如果有多台备库出现此类情况，主库会累积更多闲置连接，占用额外的系统资源。
• 极端场景下的数据丢失风险放大：如果主库在断连期间发生不可恢复故障，且主库未将这段时间生成的WAL归档到可靠存储，备库要等60分钟才会发现异常，此时无法获取故障前最后60分钟的WAL数据，数据丢失范围会比默认超时场景更大。

RPO是否会升高？ #

RPO（恢复点目标）衡量的是故障发生后，系统能恢复到的最近数据点与故障点的时间差。

• 正常复制状态下：不会升高RPO。异步复制模式下，主库会持续推送WAL到备库，超时参数不影响正常的WAL传输速率，备库数据仍保持准实时同步。
• 故障场景下：RPO会显著升高。比如主库突然宕机，而备库此时因网络中断或主库无响应未及时检测到异常，要等60分钟才会停止等待。若主库故障前最后60分钟的WAL未同步到备库（异步复制不保证WAL必达），备库无法恢复这部分数据，RPO从原本最大1分钟变为最大60分钟。

内容的提问来源于stack exchange，提问作者Fabrice Chapuis