PG 高可用

• 1: RPO 利弊权衡
• 2: RTO 利弊权衡
• 3: 故障切换模型
• 3.1: 被动故障切换
• 3.2: 主动故障检测
• 4: 服务接入

1 - RPO 利弊权衡

RPO（Recovery Point Objective，恢复点目标）定义了在主库发生故障时，允许丢失的最大数据量。

对于金融交易这类数据完整性至关重要的场景，通常要求 RPO = 0，即不允许任何数据丢失；

然而更为严格的 RPO 指标是有代价的，它会引入更高的写入延迟，降低系统吞吐量，并且存在从库故障导致主库不可用的风险。 因此对于常规场景，通常可以接受一定量的数据丢失（例如允许丢失不超过 1MB 的数据），以换取更高的可用性与性能。

利弊权衡

通常在异步复制场景下，从库和主库之间会存在一定的复制延迟（取决于网络和吞吐量，正常在 10KB-100KB / 100µs-10ms 的数量级）， 这意味着当主库发生故障时，从库可能还没有完全同步主库的最新数据。这时候如果出现故障切换，新的主库可能会丢失一些尚未复制的数据。

潜在数据丢失量的上限由 pg_rpo 参数控制，默认为 1048576 （1MB），这意味着在故障转移期间最多可以容忍 1MiB 的数据丢失。

当集群主库宕机时，如果有任何一个从库的复制延迟在这个值以内，Pigsty 将自动提升该从库为新的主库。 然而当所有从库副本的复制延迟都超出这个阈值时，Pigsty 将拒绝进行 [自动故障切换] 以避免数据丢失。 此时需要人工介入进行决策 —— 等待主库恢复（可能永远也不会恢复），还是接受数据损失并强制提升一个从库为新的主库。

您需要根据业务的需求偏好配置这个值，在 可用性 和 一致性 之间进行 利弊权衡。 增大这个值可以提高自动故障切换的成功率，但也会增加潜在的数据丢失量上限。

当您指定 pg_rpo = 0 时，Pigsty 将启用 同步复制，确保主库在确认至少一个从库持久化数据后才返回写入成功。 这种配置能确保没有复制延迟，但会带来显著的写入延迟，并降低整体的吞吐量。

flowchart LR
    A([主库故障]) --> B{同步复制?}

    B -->|否| C{延迟 < RPO?}
    B -->|是| D{同步从库<br/>可用?}

    C -->|是| E[有损自动故障切换<br/>RPO < 1MB]
    C -->|否| F[拒绝自动切换<br/>等待主库恢复<br/>或人工介入决策]

    D -->|是| G[无损自动故障切换<br/>RPO = 0]
    D -->|否| H{严格模式?}

    H -->|否| C
    H -->|是| F

    style A fill:#dc3545,stroke:#b02a37,color:#fff
    style E fill:#F0AD4E,stroke:#146c43,color:#fff
    style G fill:#198754,stroke:#146c43,color:#fff
    style F fill:#BE002F,stroke:#565e64,color:#fff

保护模式

Pigsty 提供三种保护模式，以帮助用户在不同的 RPO 要求下进行利弊权衡，类似于 Oracle Data Guard 的数据保护模式。

实现原理

三种保护模式的区别在于 Patroni 的两个核心参数：synchronous_mode 与 synchronous_mode_strict 如何配置：

• synchronous_mode：Patroni 是否启用同步复制，如果启用，再看 synchronous_mode_strict 是否启用严格同步模式。
• synchronous_mode_strict = false，默认配置，允许当从库故障时降级为异步模式，主库继续服务（最大可用性）
• synchronous_mode_strict = true，禁止降级，主库停止写入直到同步从库恢复（最大保护）

通常情况下，您只需要将 pg_rpo 参数设置为 0，即可打开 synchronous_mode 开关，启用 最大可用性模式。 如果您使用 pg_conf = crit.yml 模板，则会同时额外打开 synchronous_mode_strict 严格模式开关，启用 最大保护模式。

当然，您可以直接按需 配置 这些 Patroni 参数，您还可以参阅 Patroni 与 PostgreSQL 文档，通过配置实现更强的数据保护，例如：

• 可以指定指定 同步从库列表，配置更多同步从库以提高容灾能力，使用法定人数同步，甚至要求所有从库都执行同步提交。
• 您可以 配置 synchronous_commit: 'remote_apply'，严格确保主从读写一致性。（Oracle 最大保护模式相当于 remote_write）

配置建议

最大性能模式（异步复制）是 Pigsty 默认使用的模式，对于绝大多数业务来说已经足够使用。 容许故障时丢失少量数据（正常在 几KB - 几百KB 的数量级），换来更大的性能吞吐量与服务可用性水平，是常规业务场景的推荐配置。 在这种情况下，您可以通过 pg_rpo 参数调整允许的最大数据丢失量，以适应不同的业务需求。

最大可用性模式（同步复制）适用于对据完整性要求高的场景，不允许数据丢失。 在这种模式下，最少需要一主一从的两节点 PostgreSQL 集群才有意义。 将 pg_rpo 设置为 0 即可启用该模式。

最大保护模式 （严格同步复制） 适用于金融交易、医疗记录等对数据完整性要求极高的场景，我们建议至少使用一主二从的三节点集群， 因为两节点的情况下，只要从库故障，主库就会停止写入，导致业务不可用，这会降低系统的整体可靠性。而三节点的规格下，如果只有一个从库故障，主库仍然可以继续服务。

2 - RTO 利弊权衡

RTO（Recovery Time Objective，恢复时间目标）定义了在主库发生故障时，系统恢复写入能力所需的最长时间。

对于核心交易系统这类可用性至关重要的场景，通常要求 RTO 尽可能短，例如一分钟内。

然而更短的 RTO 指标是有代价的，它会增加误切风险：网络抖动可能被误判为故障，导致不必要的故障切换。 因此对于跨机房/跨地域部署的场景，通常需要放宽 RTO 要求（例如 1-2 分钟），以降低误切风险。

利弊权衡

故障切换时的不可用时长上限由 pg_rto 参数控制。Pigsty 提供了四种预设的 RTO 模式： fast、norm、safe、wide，分别针对不同的网络条件与部署场景进行了优化，默认使用 norm 模式（约 45 秒）。 您也可以使用秒数直接指定 RTO 上限，系统会自动映射到最接近的模式。

当主库发生故障时，整个恢复流程涉及多个阶段：Patroni 检测故障、DCS 锁过期、新主选举、执行 promote、HAProxy 感知新主。 减小 RTO 意味着缩短各阶段的超时时间，这会使集群对网络抖动更加敏感，从而增加误切风险。

您需要根据实际网络条件选择合适的模式，在 恢复速度 与 误切风险 之间取得平衡。 网络质量越差，越应该选择保守的模式；网络质量越好，越可以选择激进的模式。

flowchart LR
    A([主库故障]) --> B{Patroni<br/>检测到?}

    B -->|PG崩溃| C[尝试本地重启]
    B -->|节点宕机| D[等待 TTL 过期]

    C -->|成功| E([本地恢复])
    C -->|失败/超时| F[释放 Leader 锁]

    D --> F
    F --> G[从库竞选]
    G --> H[执行 Promote]
    H --> I[HAProxy 感知]
    I --> J([服务恢复])

    style A fill:#dc3545,stroke:#b02a37,color:#fff
    style E fill:#198754,stroke:#146c43,color:#fff
    style J fill:#198754,stroke:#146c43,color:#fff

四种模式

Pigsty 提供四种 RTO 模式，以帮助用户在不同的网络条件下进行利弊权衡。

RTO时序图

Patroni / PG HA 有两条关键故障路径，详细的 RTO 时序分析请参阅：主动故障检测 与 被动租约过期。

实现原理

四种 RTO 模式的区别在于以下 10 个 Patroni 与 HAProxy HA 相关参数如何配置。

Patroni 参数

• ttl：Leader 锁生存时间，主库须在此时间内续租，否则锁过期触发选举，直接决定被动故障的检测延迟。
• loop_wait：Patroni 主循环间隔，每个循环执行一次健康检查与状态同步，影响故障发现的及时性。
• retry_timeout：DCS 操作重试超时，网络分区时 Patroni 在此期间持续重试，超时后主库主动降级防止脑裂。
• primary_start_timeout：PG 崩溃后 Patroni 尝试本地重启的等待时间，超时后释放 Leader 锁触发切换。
• safety_margin：Watchdog 安全边际，确保故障时有足够时间触发系统重启，避免脑裂。

HAProxy 参数

• inter：正常状态下的健康检查间隔，服务状态稳定时使用。
• fastinter：状态变化期的检查间隔，检测到状态变化时使用更短间隔加速确认。
• downinter：DOWN 状态下的检查间隔，服务标记为 DOWN 后使用此间隔探测恢复。
• rise：标记 UP 所需连续成功次数，新主上线后需连续通过 rise 次检查才能接收流量。
• fall：标记 DOWN 所需连续失败次数，服务需连续失败 fall 次才会被标记为 DOWN。

关键约束

Patroni 核心约束：确保主库能在 TTL 过期前完成降级，防止脑裂。

配置建议

fast 模式 适用于对 RTO 要求极高的场景，但需要确保网络质量足够好（延迟 < 1ms，极低丢包率）。 建议仅在同机柜或同交换机部署时使用，并在生产环境充分测试后再启用。

norm 模式（默认）是 Pigsty 默认使用的配置，对于绝大多数同机房部署的业务来说已经足够使用。 平均 21 秒的恢复时间在可接受范围内，同时提供了合理的容错窗口，避免网络抖动导致的误切。

safe 模式 适用于同城跨机房部署，网络延迟较高或存在偶发抖动的场景。 更长的容错窗口可以有效避免网络抖动导致的误切，是跨机房容灾的推荐配置。

wide 模式 适用于跨地域甚至跨大洲部署，网络延迟高且可能存在公网级别的丢包率。 这种场景下，稳定性比恢复速度更重要，因此使用极宽的容错窗口来确保极低的误切率。

通常只需将 pg_rto 设为模式名称，Pigsty 会自动配置 Patroni 与 HAProxy 参数。 为了保持向后兼容性，Pigsty 仍然支持直接使用秒数配置 RTO，但效果相当于指定 norm 模式。

配置模式实际上是从 pg_rto_plan 中加载对应参数集，您可以修改或覆盖此配置以实现自定义 RTO 策略。

pg_rto_plan:  # [ttl, loop, retry, start, margin, inter, fastinter, downinter, rise, fall]
  fast: [ 20  ,5  ,5  ,15 ,5  ,'1s' ,'0.5s' ,'1s' ,3 ,3 ]  # rto < 30s
  norm: [ 30  ,5  ,10 ,25 ,5  ,'2s' ,'1s'   ,'2s' ,3 ,3 ]  # rto < 45s
  safe: [ 60  ,10 ,20 ,45 ,10 ,'3s' ,'1.5s' ,'3s' ,3 ,3 ]  # rto < 90s
  wide: [ 120 ,20 ,30 ,95 ,15 ,'4s' ,'2s'   ,'4s' ,3 ,3 ]  # rto < 150s

3 - 故障切换模型

Patroni 故障按故障对象分类可以分为以下 10 类，按照检测路径不同，可以进一步归纳为五类，在本节内详细展开。

但是在 RTO 计算上，最终所有故障都会收敛到两条路径上，本节深入探讨了这两种情况下的 RTO 上下限与均值。

• Patroni 失联后被动触发选举：
• Patroni 主动检测故障并切换:

flowchart LR
    A([主库故障]) --> B{Patroni<br/>检测到?}

    B -->|PG崩溃| C[尝试本地重启]
    B -->|节点宕机| D[等待 TTL 过期]

    C -->|成功| E([本地恢复])
    C -->|失败/超时| F[释放 Leader 锁]

    D --> F
    F --> G[从库竞选]
    G --> H[执行 Promote]
    H --> I[HAProxy 感知]
    I --> J([服务恢复])

    style A fill:#dc3545,stroke:#b02a37,color:#fff
    style E fill:#198754,stroke:#146c43,color:#fff
    style J fill:#198754,stroke:#146c43,color:#fff

3.1 - 被动故障切换

RTO 时序图

故障模型

被动故障与主动故障的核心区别：

在被动故障场景中，Patroni 随节点一起宕机，无法主动释放 Leader Key。 DCS 中的租约只能等待 TTL 自然过期后触发集群选举。

时序分析

阶段 1：租约过期

Patroni 主库会在每个 loop_wait 周期刷新 Leader Key，将 TTL 重置为配置值。

时间线：
     t-loop        t          t+ttl-loop    t+ttl
       |           |              |           |
    上次刷新    故障发生        最好情况      最坏情况
       |←── loop ──→|              |           |
       |←──────────── ttl ─────────────────────→|

• 最好情况：故障发生在即将刷新租约之前（距上次刷新已过 loop），剩余 TTL = ttl - loop
• 最坏情况：故障发生在刚刷新租约之后，需等待完整 ttl
• 平均情况：ttl - loop/2

阶段 2：从库检测

从库在 loop_wait 周期醒来后检查 DCS 中的 Leader Key 状态。

时间线：
    租约过期      从库醒来
       |            |
       |←── 0~loop ─→|

• 最好情况：租约过期时从库恰好醒来，等待 0
• 最坏情况：租约过期后从库刚进入睡眠，等待 loop
• 平均情况：loop/2

阶段 3：抢锁提拔

从库发现 Leader Key 过期后，开始竞选过程，获得 Leader Key 的从库执行 pg_ctl promote，将自己提升为新主库。

1. 通过 Rest API，并行发起查询，查询各从库的复制位置，通常 10ms，硬编码 2 秒超时。
2. 比较 WAL 位置，确定最优候选，各从库尝试创建 Leader Key（CAS 原子操作）
3. 执行 pg_ctl promote 提升自己为主库（很快，通常忽略不计）

选举流程：
  从库A ──→ 查询复制位置 ──→ 比较 ──→ 尝试抢锁 ──→ 成功
  从库B ──→ 查询复制位置 ──→ 比较 ──→ 尝试抢锁 ──→ 失败

• 最好情况：单从库或直接抢到锁并提升，常数开销 0.1s
• 最坏情况：DCS API 调用超时：2s
• 平均情况：1s 常数开销

阶段 4：健康检查

HAProxy 检测新主库上线，需要连续 rise 次健康检查成功。

检测时序：
  新主提升    首次检查    第二次检查   第三次检查（UP）
     |          |           |           |
     |←─ 0~inter ─→|←─ fast ─→|←─ fast ─→|

• 最好情况：新主提升时恰好赶上检查，(rise-1) × fastinter
• 最坏情况：新主提升后刚错过检查，(rise-1) × fastinter + inter
• 平均情况：(rise-1) × fastinter + inter/2

RTO 公式

将各阶段时间相加，得到总 RTO：

最好情况

平均情况

最坏情况

模型计算

将四种 RTO 模型的参数带入上面的公式：

pg_rto_plan:  # [ttl, loop, retry, start, margin, inter, fastinter, downinter, rise, fall]
  fast: [ 20  ,5  ,5  ,15 ,5  ,'1s' ,'0.5s' ,'1s' ,3 ,3 ]  # rto < 30s
  norm: [ 30  ,5  ,10 ,25 ,5  ,'2s' ,'1s'   ,'2s' ,3 ,3 ]  # rto < 45s
  safe: [ 60  ,10 ,20 ,45 ,10 ,'3s' ,'1.5s' ,'3s' ,3 ,3 ]  # rto < 90s
  wide: [ 120 ,20 ,30 ,95 ,15 ,'4s' ,'2s'   ,'4s' ,3 ,3 ]  # rto < 150s

四种模式计算结果（单位：秒，格式：min / avg / max）

3.2 - 主动故障检测

RTO 时序图

故障模型

主动故障与被动故障的核心区别：

在主动故障场景中，Patroni 仍然存活，能够主动检测到 PG 崩溃并尝试重启。 如果重启成功，服务自愈；如果超时仍未恢复，Patroni 会主动释放 Leader Key，触发集群选举。

时序分析

阶段 1：故障检测

Patroni 在每个 loop_wait 周期检查 PostgreSQL 状态（通过 pg_isready 或检查进程）。

时间线：
    上次检测      PG崩溃      下次检测
       |           |           |
       |←── 0~loop ─→|          |

• 最好情况：PG 恰好在 Patroni 检测前崩溃，立即被发现，等待 0
• 最坏情况：PG 刚检测完就崩溃，需等待下一个周期，等待 loop
• 平均情况：loop/2

阶段 2：重启超时

Patroni 检测到 PG 崩溃后，会尝试重启 PostgreSQL。此阶段有两种可能的结果：

时间线：
  检测到崩溃     尝试重启     重启成功/超时
      |           |             |
      |←──── 0 ~ start ────────→|

路径 A：自愈成功（最好情况）

• PG 成功重启，服务恢复
• 不触发故障切换，RTO 极短
• 等待时间：0（相对于 Failover 路径）

路径 B：需要 Failover（平均/最坏情况）

• 等待 primary_start_timeout 超时后 PG 仍未恢复
• Patroni 主动释放 Leader Key
• 等待时间：start

注意：平均情况假设需要进行故障切换。如果 PG 能够快速自愈，则整体 RTO 会大幅降低。

阶段 3：从库检测

从库在 loop_wait 周期醒来后检查 DCS 中的 Leader Key 状态。当主库 Patroni 释放 Leader Key 后，从库发现后开始竞选。

时间线：
    租约释放      从库醒来
       |            |
       |←── 0~loop ─→|

• 最好情况：租约释放时从库恰好醒来，等待 0
• 最坏情况：租约释放后从库刚进入睡眠，等待 loop
• 平均情况：loop/2

阶段 4：抢锁提拔

从库发现 Leader Key 空缺后，开始竞选过程，获得 Leader Key 的从库执行 pg_ctl promote，将自己提升为新主库。

1. 通过 Rest API，并行发起查询，查询各从库的复制位置，通常 10ms，硬编码 2 秒超时。
2. 比较 WAL 位置，确定最优候选，各从库尝试创建 Leader Key（CAS 原子操作）
3. 执行 pg_ctl promote 提升自己为主库（很快，通常忽略不计）

选举流程：
  从库A ──→ 查询复制位置 ──→ 比较 ──→ 尝试抢锁 ──→ 成功
  从库B ──→ 查询复制位置 ──→ 比较 ──→ 尝试抢锁 ──→ 失败

• 最好情况：单从库或直接抢到锁并提升，常数开销 0.1s
• 最坏情况：DCS API 调用超时：2s
• 平均情况：1s 常数开销

阶段 5：健康检查

HAProxy 检测新主库上线，需要连续 rise 次健康检查成功。

检测时序：
  新主提升    首次检查    第二次检查   第三次检查（UP）
     |          |           |           |
     |←─ 0~inter ─→|←─ fast ─→|←─ fast ─→|

• 最好情况：新主提升时恰好赶上检查，(rise-1) × fastinter
• 最坏情况：新主提升后刚错过检查，(rise-1) × fastinter + inter
• 平均情况：(rise-1) × fastinter + inter/2

RTO 公式

将各阶段时间相加，得到总 RTO：

最好情况（PG 瞬间自愈）

平均情况（需要 Failover）

最坏情况

模型计算

将四种 RTO 模型的参数带入上面的公式：

pg_rto_plan:  # [ttl, loop, retry, start, margin, inter, fastinter, downinter, rise, fall]
  fast: [ 20  ,5  ,5  ,15 ,5  ,'1s' ,'0.5s' ,'1s' ,3 ,3 ]  # rto < 30s
  norm: [ 30  ,5  ,10 ,25 ,5  ,'2s' ,'1s'   ,'2s' ,3 ,3 ]  # rto < 45s
  safe: [ 60  ,10 ,20 ,45 ,10 ,'3s' ,'1.5s' ,'3s' ,3 ,3 ]  # rto < 90s
  wide: [ 120 ,20 ,30 ,95 ,15 ,'4s' ,'2s'   ,'4s' ,3 ,3 ]  # rto < 150s

四种模式计算结果（单位：秒，格式：min / avg / max）

与被动故障对比

RTO 对比（平均情况）：

分析：在 fast 和 norm 模式下，主动故障的 RTO 略高于被动故障，因为需要等待 primary_start_timeout（start）； 但在 safe 和 wide 模式下，由于 start < ttl - loop，主动故障反而更快。 不过主动故障有自愈的可能性，最好情况下 RTO 可以极短。

4 - 服务接入

分离读写操作，正确路由流量，稳定可靠地交付 PostgreSQL 集群提供的能力。

服务 是一种抽象：它是数据库集群对外提供能力的形式，并封装了底层集群的细节。

服务对于生产环境中的 稳定接入 至关重要，在 高可用 集群自动故障时方显其价值，单机用户 通常不需要操心这个概念。

单机用户

“服务” 的概念是给生产环境用的，个人用户/单机集群可以不折腾，直接拿实例名/IP地址访问数据库。

例如，Pigsty 默认的单节点 pg-meta.meta 数据库，就可以直接用下面三个不同的用户连接上去。

psql postgres://dbuser_dba:DBUser.DBA@10.10.10.10/meta     # 直接用 DBA 超级用户连上去
psql postgres://dbuser_meta:DBUser.Meta@10.10.10.10/meta   # 用默认的业务管理员用户连上去
psql postgres://dbuser_view:DBUser.View@pg-meta/meta       # 用默认的只读用户走实例域名连上去

服务概述

在真实世界生产环境中，我们会使用基于复制的主从数据库集群。集群中有且仅有一个实例作为领导者（主库）可以接受写入。 而其他实例（从库）则会从持续从集群领导者获取变更日志，与领导者保持一致。同时，从库还可以承载只读请求，在读多写少的场景下可以显著分担主库的负担， 因此对集群的写入请求与只读请求进行区分，是一种十分常见的实践。

此外对于高频短连接的生产环境，我们还会通过连接池中间件（Pgbouncer）对请求进行池化，减少连接与后端进程的创建开销。但对于ETL与变更执行等场景，我们又需要绕过连接池，直接访问数据库。 同时，高可用集群在故障时会出现故障切换（Failover），故障切换会导致集群的领导者出现变更。因此高可用的数据库方案要求写入流量可以自动适配集群的领导者变化。 这些不同的访问需求（读写分离，池化与直连，故障切换自动适配）最终抽象出 服务 （Service）的概念。

通常来说，数据库集群都必须提供这种最基础的服务：

• 读写服务（primary） ：可以读写数据库

对于生产数据库集群，至少应当提供这两种服务：

• 读写服务（primary） ：写入数据：只能由主库所承载。
• 只读服务（replica） ：读取数据：可以由从库承载，没有从库时也可由主库承载

此外，根据具体的业务场景，可能还会有其他的服务，例如：

• 默认直连服务（default） ：允许（管理）用户，绕过连接池直接访问数据库的服务
• 离线从库服务（offline） ：不承接线上只读流量的专用从库，用于ETL与分析查询
• 同步从库服务（standby） ：没有复制延迟的只读服务，由 同步备库 /主库处理只读查询
• 延迟从库服务（delayed） ：访问同一个集群在一段时间之前的旧数据，由 延迟从库 来处理

接入服务

Pigsty的服务交付边界止步于集群的HAProxy，用户可以用各种手段访问这些负载均衡器。

典型的做法是使用 DNS 或 VIP 接入，将其绑定在集群所有或任意数量的负载均衡器上。

你可以使用不同的 主机 & 端口 组合，它们以不同的方式提供 PostgreSQL 服务。

主机

端口

Pigsty 使用不同的 端口 来区分 pg services

组合

# 通过集群域名访问
postgres://test@pg-test:5432/test # DNS -> L2 VIP -> 主直接连接
postgres://test@pg-test:6432/test # DNS -> L2 VIP -> 主连接池 -> 主
postgres://test@pg-test:5433/test # DNS -> L2 VIP -> HAProxy -> 主连接池 -> 主
postgres://test@pg-test:5434/test # DNS -> L2 VIP -> HAProxy -> 备份连接池 -> 备份
postgres://dbuser_dba@pg-test:5436/test # DNS -> L2 VIP -> HAProxy -> 主直接连接 (用于管理员)
postgres://dbuser_stats@pg-test:5438/test # DNS -> L2 VIP -> HAProxy -> 离线直接连接 (用于 ETL/个人查询)

# 通过集群 VIP 直接访问
postgres://test@10.10.10.3:5432/test # L2 VIP -> 主直接访问
postgres://test@10.10.10.3:6432/test # L2 VIP -> 主连接池 -> 主
postgres://test@10.10.10.3:5433/test # L2 VIP -> HAProxy -> 主连接池 -> 主
postgres://test@10.10.10.3:5434/test # L2 VIP -> HAProxy -> 备份连接池 -> 备份
postgres://dbuser_dba@10.10.10.3:5436/test # L2 VIP -> HAProxy -> 主直接连接 (用于管理员)
postgres://dbuser_stats@10.10.10.3::5438/test # L2 VIP -> HAProxy -> 离线直接连接 (用于 ETL/个人查询)

# 直接指定任何集群实例名
postgres://test@pg-test-1:5432/test # DNS -> 数据库实例直接连接 (单例访问)
postgres://test@pg-test-1:6432/test # DNS -> 连接池 -> 数据库
postgres://test@pg-test-1:5433/test # DNS -> HAProxy -> 连接池 -> 数据库读/写
postgres://test@pg-test-1:5434/test # DNS -> HAProxy -> 连接池 -> 数据库只读
postgres://dbuser_dba@pg-test-1:5436/test # DNS -> HAProxy -> 数据库直接连接
postgres://dbuser_stats@pg-test-1:5438/test # DNS -> HAProxy -> 数据库离线读/写

# 直接指定任何集群实例 IP 访问
postgres://test@10.10.10.11:5432/test # 数据库实例直接连接 (直接指定实例, 没有自动流量分配)
postgres://test@10.10.10.11:6432/test # 连接池 -> 数据库
postgres://test@10.10.10.11:5433/test # HAProxy -> 连接池 -> 数据库读/写
postgres://test@10.10.10.11:5434/test # HAProxy -> 连接池 -> 数据库只读
postgres://dbuser_dba@10.10.10.11:5436/test # HAProxy -> 数据库直接连接
postgres://dbuser_stats@10.10.10.11:5438/test # HAProxy -> 数据库离线读-写

# 智能客户端：通过URL读写分离
postgres://test@10.10.10.11:6432,10.10.10.12:6432,10.10.10.13:6432/test?target_session_attrs=primary
postgres://test@10.10.10.11:6432,10.10.10.12:6432,10.10.10.13:6432/test?target_session_attrs=prefer-standby