你以为高可用只是数据库的事？
配置前的检查
公有云平台上自建High看似简单，真正落地时却很容易踩坑。想象一个场景：你把 PostgreSQL 主从复制搭建好了，Patroni 也配好了自动切换，甚至还在 slave 上挂了 read-only 节点。一切看起来完美。然后某天主机宕机，切换成功，但业务却连不上数据库了——因为业务代码里写死了主库的私网 IP，而那个 IP 还挂在已经挂掉的旧主机上。这样的案例，在真实的公有云生产环境中每天都在发生。
网络高可用，就是确保数据库集群的入口（IP 或域名）不会因为单点故障而失效，并且在切换时能够让流量平滑地转移到新的主节点。本文不讲枯燥的配置文件参数，而是从根本概念出发，帮你建立起正确的网络高可用认知。
什么是“网络高可用”？拆开来看其实就两件事
实际操作要点
第一，链路层面的冗余。如果数据库只有一张网卡、一条上联链路，那交换机故障、网卡坏掉、甚至网线被踢到，都会导致整个集群失联。在公有云上，虽然虚拟交换机有冗余，但实例自身的 ENI（弹性网卡）依然有单点风险。主流做法是给云服务器绑定两张网卡（主备），或者利用云平台提供的高可用虚拟 IP（HaVip）来实现二层漂移。
第二，服务入口的故障转移。数据库的客户端（你的业务应用）必须知道该连谁。如果写死 IP，主从切换后你就要手动改配置；如果用域名，DNS 的 TTL 缓存可能导致业务在切换后的一两分钟内还在尝试连接已死掉的旧主。这期间，部分请求会失败。真正的网络高可用，需要让切换对客户端几乎无感知。
公有云网络环境跟 IDC 有什么不同？
故障定位思路
很多从传统 IDC 迁移到云上的运维人员，第一反应是把机房的 Keepalived + VIP 方案直接搬到云上。结果发现：VIP 无法正常漂移。原因在于公有云 VPC 默认禁止 ARP 广播——这是为了隔离租户、防止网络攻击。同一个 VPC 内的两台机器无法直接通过 ARP 抢夺 IP，传统 VIP 方案失效。
公有云厂商针对这个问题给出了不同解决方案：
– 阿里云：HaVip（高可用虚拟IP），需要在 VPC 内开启 ARP 代答功能，配合 Keepalived 使用；
– 腾讯云：提供 VPC 内的 VIP 支持（需在控制台配置），同样依赖云原生 API 来实现 IP 漂移；
– AWS、Azure：不支持浮动 IP，推荐使用 Network Load Balancer（NLB）做四层转发，后端挂载所有数据库节点，通过健康检查自动剔除故障节点。
理解这一点至关重要：在公有云上，你需要放弃“二层浮动 IP”的传统思维，转而拥抱“三层转发”或“云 API 驱动”的方案。
流复制与主从切换——网络延迟是最隐蔽的杀手
故障定位思路
PostgreSQL 的高可用通常基于流复制（Streaming Replication）。主库把 WAL 日志实时发送到从库。如果主从之间的网络延迟过高，从库永远追不上主库的进度——此时主库一挂，切到从库会导致数据丢失（即使配置了同步复制，也会牺牲可用性）。
更可怕的是网络分区（脑裂）：主库和从库之间的网络断了，但两边都觉得自己是主，同时接受写入。一旦网络恢复，数据冲突根本没法自动解决。这是因为很多高可用管理工具（比如 Patroni）依靠 etcd 或 Consul 做分布式锁，但如果 etcd 集群本身因为网络不可达而选出多个 Leader，问题同样会出现。
所以，网络高可用不仅仅是“入口不掉线”，还包括“集群内部节点间的可靠通信”。建议将数据库集群的节点部署在同一 VPC 下的不同可用区里，并且保证各可用区之间的延迟 < 2ms（公有云同城延迟通常满足）。同时，一定要为 etcd/Patroni 等组件配置故障域隔离（多 AZ 部署 etcd 需要偶数个节点+仲裁机制）。
进阶阅读：此处可内链到“公有云平台上自建High性能优化”指南。
相关阅读：此处可内链到“公有云平台上自建High常见问题”专题。
三个主流方案，哪种适合你的场景？
方案一：云原生负载均衡器 + 后端静态组
最简单可靠的做法：在数据库集群前挂一个四层负载均衡（如阿里云 SLB、腾讯云 CLB、AWS NLB），监听 5432 端口，后端指向所有数据库节点。使用 Patroni 或 Repmgr 做自动主从切换，切换后，通过健康检查（端口探活或脚本探活）把新主库加入后端组，同时剔除旧主（或者让旧主因为服务不可用被自动摘除）。
优点：完全避免 VIP 漂移问题，DNS 也只需解析到负载均衡的 IP，切换对业务零感知（只要负载均衡的健康检查足够快）。
缺点：增加了一层网络开销（一般影响 < 0.1ms），而且负载均衡本身也有单点风险——不过公有云 LB 自带高可用，不必担心。
方案二：HaVip（浮动 IP）+ Keepalived
适合对延迟极其敏感、不希望通过 LB 的场景。需要云平台开放 HaVip 功能（目前阿里云、腾讯云支持）。配置步骤大致为：申请一个 HaVip，绑定到 VPC 内；在两台数据库节点上安装 Keepalived，使用虚拟路由冗余协议（VRRP）抢夺 HaVip；当主库宕机时，HaVip 自动飘到备用节点。
关键注意事项：
1. 必须启用云平台提供的 HaVip 控制台创建，并关联好安全组；
2. Keepalived 不能使用标准组播，需要修改为使用单播（unicast）——因为云上不传递组播广播包；
3. 数据面做 Keepalived 检测时，不能只依赖 ping，要检测数据库实际端口 5432 是否存活。
方案三：通过 Cloud API 驱动弹性 IP 漂移
在一些不允许二层漂移的云（如 AWS、Azure），你可以写脚本或使用现成工具（如 Patroni 的 callbacks 或 Raft 集成），在主从切换时调用云平台的 API，解绑旧主机的弹性公网 IP/私网 IP，并绑定到新主机上。这种方式延迟较高（一般需要几秒），但逻辑最清晰。
想继续深入：此处可内链到“公有云平台上自建High优化清单”文章。
最容易忽视的两个网络细节
容易忽略的细节
细节一：安全组/网络 ACL 的连通性。很多人在调试 PostgreSQL 流复制时，忘记打开从库到主库的 5432 端口，或者只开了单向规则。更隐蔽的问题是：云平台的安全组有状态 vs 无状态的区别。如果使用了网络 ACL（无状态），必须显式添加入站和出站规则，否则连接会被丢弃。
细节二：DNS 缓存和连接池。即使你用了负载均衡，如果应用端使用了连接池（如 PgBouncer、应用程序的连接池），并且连接池内部缓存了旧的 IP，切换后还是会出现连接失败。建议在切换脚本中加入重启连接池或清空缓存的步骤，或者在连接字符串中使用短 TTL 的 DNS 记录（如 TTL=5 秒）。
公有云平台上自建High：什么时候应该放弃自建，用云原生数据库服务？
故障定位思路
如果你团队的运维能力偏弱，或者业务对 RPO（恢复点目标）要求极高（< 1s），其实更推荐使用云厂商托管的 PostgreSQL（如 RDS PostgreSQL、Aurora）。它们内置了存储层多副本、自动故障切换、跨可用区部署，网络高可用完全由云平台负责。自建虽然自由度更高，但需要团队深入理解网络原理、熟练使用云 API，并且愿意投入运维成本。
反之，如果你的业务对数据库配置有特殊要求（比如需要特定的插件、自定义内核参数、超大规模连接数），或者你需要跨云/混合云部署，那么自建 + 做好网络高可用就是必须迈过的坎。
总结：网络高可用不是选项，是及格线与公有云平台上自建High
验证与回滚
很多人在搭建 PostgreSQL 高可用集群时，往往只验证了“主从切换成功”这一个指标，却忽略了网络层面的三个核心指标：
– 切换后客户端多久能恢复连接（RTO）
– 切换过程中是否出现数据不一致（脑裂）
– 网络单点是否存在（负载均衡器、HaVip 本身）
从今天开始，当你再规划数据库架构时，请把网络拓扑图画清楚，明确每一层的故障转移能力，并且定期做混沌工程演练：拔掉主库网线、关闭负载均衡器、模拟 DNS 故障。只有让网络高可用经得起这些考验，你的 PostgreSQL 集群才配得上“高可用”三个字。把这些步骤跑通后，公有云平台上自建High基本就能稳定落地。
延伸阅读