CloudNativePG 中流式探针的滞后比较逻辑问题分析

问题背景

在 CloudNativePG 项目中，当使用流式复制（streaming replication）作为启动和就绪探针（startup/readiness probe）策略时，系统会通过 SQL 查询来检查副本的 WAL 日志滞后情况。这个机制对于确保数据库集群中各节点数据一致性至关重要。

问题现象

当前实现中存在一个逻辑缺陷：当配置的 maximumLag 参数设置为 0 时，就绪探针永远不会成功。这是因为在 SQL 查询中使用了严格小于（<）比较运算符，导致当实际滞后值等于 0 时（即 0 < 0），条件判断结果为假。

技术分析

在 pkg/management/postgres/webserver/probes/streaming.go 文件中，系统执行以下核心 SQL 查询逻辑：

WITH lag AS (
  SELECT
    (latest_end_lsn - pg_last_wal_replay_lsn()) AS value,
    latest_end_time
  FROM pg_catalog.pg_stat_wal_receiver
)
SELECT
  CASE
    WHEN NOT pg_is_in_recovery()
  THEN true
    WHEN (SELECT coalesce(setting, '') = '' FROM pg_catalog.pg_settings WHERE name = 'primary_conninfo')
  THEN true
    WHEN (SELECT value FROM lag) < \$1
  THEN true
  ELSE false
  END AS ready_to_start,
  COALESCE((SELECT value FROM lag), 0) AS lag,
  COALESCE((SELECT latest_end_time FROM lag), '-infinity') AS latest_end_time

问题出在 (SELECT value FROM lag) < \$1 这一条件判断上。当 maximumLag 参数配置为 0 时，这个条件实际上变成了 0 < 0，这在布尔逻辑中永远为假。

解决方案

正确的做法应该是将严格小于（<）改为小于等于（<=）。这样修改后：

1. 当 maximumLag 为 0 时，0 <= 0 为真，探针能够正确通过
2. 对于其他正值情况，逻辑保持不变
3. 更准确地反映了"不超过最大允许滞后"的业务需求

修改后的条件应为：

WHEN (SELECT value FROM lag) <= \$1

影响范围

这个问题会影响以下场景：

• 使用流式复制探针策略的副本节点
• 当 maximumLag 参数显式设置为 0 时
• 在启动和就绪探针检查时

最佳实践建议

对于生产环境配置，建议：

1. 明确设置合理的 maximumLag 值，通常不应设为 0
2. 理解严格小于和小于等于在滞后控制中的不同语义
3. 在关键业务系统中，应该测试探针在各种滞后场景下的行为

这个问题的修复将提高 CloudNativePG 在严格一致性要求场景下的可靠性，确保探针机制能够正确反映副本节点的真实状态。