# 高可用 SOTA 拓扑、Etcd 暗雷与百万 QPS 连接池

> RTO/RPO 硬指标、Patroni 无共享流复制、OpenAI 8 亿用户连接池收敛与零停机迁移。

---

LLMS 索引： [llms.txt](/llms.txt)

---

数据库高可用不看云厂商代金券对赌的“几个九”，只认极端故障下的 RTO 与 RPO 硬底线。依托无共享流复制、控制面解耦与连接池收敛，单套 PostgreSQL 集群足以稳扛百万级 QPS。

## 一、高可用 SOTA 拓扑与控制面防线 {#ha-topology-and-control-plane}

### 为何别信几个九 SLA，高可用硬指标是什么？ {#rto-rpo-over-sla}

云厂商“几个九 SLA”只是故障后的代金券赔付条款，高可用硬指标唯有最多丢多少数（RPO）与多久恢复写（RTO）。Patroni 异步模式靠 `maximum_lag_on_failover` 锁死 1MB 丢数上限，金融场景用多同步从库 `remote_apply` 零丢数；同机柜最坏 RTO 压进 30 秒已是顶尖，切记改掉默认 300 秒的 `primary_start_timeout`，否则崩溃恢复会飙至 324 秒。

- [PostgreSQL 高可用到底怎么做？ · 可用性，RTO与RPO](/pg/pg-ha-sota/#可用性rto与rpo)
- [PostgreSQL 高可用到底怎么做？ · 实现原理](/pg/pg-ha-sota/#实现原理)
- [PostgreSQL 高可用到底怎么做？ · 参数配置](/pg/pg-ha-sota/#参数配置)

### 无共享流复制相比 RAC 与 Raft 赢在哪？ {#shared-nothing-vs-rac-raft}

Oracle RAC 等共享存储架构只防计算节点故障，磁盘阵列或云盘一坏照样全军覆没；CockroachDB 等 Raft 分布式库则要陪交数倍写延迟与吞吐暴跌税。Patroni + Etcd + HAProxy 无共享流复制彻底消除存储单点且只读扩展无上限：OpenAI Bohan Zhang 披露单主挂近 50 个从库便扛下 8 亿用户百万 QPS，正如探探全局 WAL 仅 110 MB/s，现代单机 PG 拥有 100～200 MB/s 写入高天花板。

- [PostgreSQL 高可用到底怎么做？ · 关于 RAC 与分布式数据库](/pg/pg-ha-sota/#关于-rac-与分布式数据库)
- [OpenAI：一套 PG 支持8亿 ChatGPT 用户 · 单机写入的真实天花板](/pg/openai-postgres/#单机写入的真实天花板)

### 高可用如何幂等接入，VIP 与 DNS 怎么选？ {#haproxy-vip-dns-access}

高可用须闭环 Patroni 自动选主与 HAProxy 自动路由：全节点对称部署 HAProxy 轮询探活，外部连任意存活节点都能透明读写。上层接入各有利弊：L2 VIP 漂移快却绑死二层交换机，DNS 无视拓扑但受制于缓存延迟，L4 VIP 可跨网段均衡并用 DPVS `toa` 留源 IP 但基建最重；同时须将名字服务、时钟、离线源、共识与监控收敛至独立“元节点”自举。

- [高可用PgSQL集群架构设计与落地 · 数据库集群](/pg/pg-ha-design/#数据库集群)
- [高可用PgSQL集群架构设计与落地 · 数据库接入](/pg/pg-ha-design/#数据库接入)
- [高可用PgSQL集群架构设计与落地 · 元节点](/pg/pg-ha-design/#元节点)

### 同步集群如何编排级联拓扑与分级故障止血？ {#sync-cascade-topology-fencing}

开启 `ANY 1` 同步提交至少需两个同步下游防单点挂死：最优拓扑是让 `pg_receivewal` 与同步备库 S 并列直连主库凑票，把远程备库 R 级联挂在 S 下，确保 S 升主后立刻有同步下游接棒。线上按角色分级止血：切主必先严密 Fencing 旧主防脑裂，事后再用 `pg_rewind` 归建。

- [PostgreSQL 常见复制拓扑方案 · 集群拓扑](/pg/replication-plan/#集群拓扑)
- [PostgreSQL 常见复制拓扑方案 · 故障恢复](/pg/replication-plan/#故障恢复)

### Linux 原生编排赢在哪，为何必锁离线源？ {#k8s-vs-linux-native-distro}

CloudNativePG 等 K8s 方案胜在控制面统一却背负沉重抽象税；Linux 原生直跑 OS 之上，故障域最小且方便直连兜底。但切忌裸连公网源手搓装包——PGDG 升级 LLVM 20 冲突系统 `bpftool` 或上游包错位破 ABI 随时让扩容翻车，必须靠发行版排雷并锁死本地离线源快照。

- [什么是 PostgreSQL 发行版？ · 四、编排的两条路：K8s 原生与 Linux 原生](/pg/what-is-pg-distro/#四编排的两条路k8s-原生与-linux-原生)
- [PostgreSQL 18 可以上生产用了吗？ · 如何在生产环境部署 PG18？](/pg/pg18-production-ready/#如何在生产环境部署-pg18)
- [不要更新！发布当日叫停：PG也躲不过大翻车 · 如何规避这样的问题](/pg/pg-faint/#如何规避这样的问题)

### 为何默认配置的 Etcd 是高可用集群定时炸弹？ {#etcd-2gb-timebomb}

Etcd 每次写入都会生成新 MVCC 版本，写满默认 2GB 配额即拒写罢工，偏偏 `auto-compaction-retention` 默认值为 `0`（不清理），常在上线数月后突然引爆生产集群。衡量基础软件成熟度的试金石正是默认配置安全：PostgreSQL 自默认开启 `AutoVacuum` 自动巡检回收后，便根除了历史垃圾自爆隐患。

- [Etcd坑了多少公司？ · etcd 的缺陷](/db/bad-etcd/#etcd-的缺陷)
- [Etcd坑了多少公司？ · PostgreSQL 的例子](/db/bad-etcd/#postgresql-的例子)

### 管控停摆如何解耦保命，黑盒商业软件怎么兜底？ {#control-data-plane-decoupling}

高可用严守“管控与数据平面解耦”：影视飓风曾遇 Etcd 2GB 写满断连，因存储隔离底层 PG 毫发无损，清理碎片后十余分钟即恢复。面对达芬奇这类无法改源码的黑盒商业软件，直接将底座换成生产级本地 PG，即可从外部赋予 LDAP 鉴权、最小权限与分钟级 PITR，多次挽回误删事故。

- [影视飓风达芬奇千万级数据库演化及实践 · 06 · EXPERIENCE：踩坑经验](/db/davinci-database/#06--experience踩坑经验)
- [影视飓风达芬奇千万级数据库演化及实践 · 老冯评论](/db/davinci-database/#老冯评论)

## 二、连接池收敛与百万 QPS 伸缩治理 {#pooling-and-million-qps}

### 千级直连为何雪崩，连接池如何扛百万 QPS？ {#pgbouncer-scale-and-congestion}

PG 一连接一进程模型在活跃连接超核数两倍时即雪崩：1500 直连写单表会打出上千 `LWLock` 等待令延迟暴涨千倍，经 PgBouncer 压至 2 条即跑满两万 TPS，探探两万连接压成 5～8 条便扛住 50 万 QPS（92 核达 233 万）。前置 HAProxy 多实例可破单核瓶颈；OpenAI 借此把建连压至 5ms，Neo Kim 披露 Cloudflare 更用 TCP Vegas 隔离慢查询。

- [你为什么不用连接池？ · 高并发连接数](/db/why-no-connection-pool/#高并发连接数)
- [令人惊叹的PostgreSQL可伸缩性 · 性能与瓶颈](/pg/pg-scalability/#性能与瓶颈)
- [OpenAI：一套 PG 支持8亿 ChatGPT 用户 · 关于连接池](/pg/openai-postgres/#关于连接池)
- [令人惊叹的PostgreSQL可伸缩性 · 4. 并发](/pg/pg-scalability/#4-并发)

### 为何不能混用连接池，三种池化模式该怎么选？ {#pgbouncer-modes-and-routing}

生产须按负载分流端口：高频在线读写强制走 PgBouncer（6432）收敛进程并缓冲切主抖动；耗时管理与离线 ETL 绕开池子直连 PG（5432）防占死连接。三种池化中唯事务模式兼顾高复用与完整事务语义，配合按库与用户隔离，还能输出细粒度 RT、秒级熔断坏租户并热重载零停机切流。

- [高可用PgSQL集群架构设计与落地 · 组件交互](/pg/pg-ha-design/#组件交互)
- [Pgbouncer快速上手 · 描述](/pg/pgbouncer-usage/#描述)
- [令人惊叹的PostgreSQL可伸缩性 · 管理灵活性](/pg/pg-scalability/#管理灵活性)

### 如何观测 PgBouncer 水位并零中断维护？ {#pgbouncer-stats-and-reload}

持续监控 `pgbouncer` 管理库须采集单调递增的 `total_*` 计数器算速率，紧盯客户端等待数 `cl_waiting` 与队首等待时长 `maxwait` 捕捉后端饱和信号。在线维护时，未开加密的本地套接字可用 `-R` 传递文件描述符完成无感热升级（严禁手敲阻塞事件循环的 `SHOW FDS`），重启后端库前执行 `PAUSE` 平滑挂起请求；切记 `query_timeout` 超时直接断连，绝不可当语句超时混用。

- [Pgbouncer快速上手 · SHOW STATS;](/pg/pgbouncer-usage/#show-stats)
- [Pgbouncer快速上手 · 默认配置](/pg/pgbouncer-usage/#默认配置)

### 单主冲刺百万 QPS 如何控写负载与杀僵尸连接？ {#openai-pg-primary-scaling}

复盘 OpenAI Bohan Zhang 实战，单主极限伸缩重在严控写入与长锁：冻结原库建表并将重写增量剥离至 Citus，只读卸载至分级从库；拆解 12 表 `JOIN`，加减列锁超时锁死 5 秒、索引强制 `CONCURRENTLY`。对卡在等待客户端送数而杀不掉的 `Active + ClientRead` 连接，须在负载均衡与连接池双侧限制最大连接寿命兜底。

- [OpenAI：一套 PG 支持8亿 ChatGPT 用户 · 将 PG 扩展到百万级 QPS](/pg/openai-postgres/#将-pg-扩展到百万级-qps)
- [OpenAI：将PostgreSQL伸缩至新阶段 · 控制主库负载](/db/openai-pg/#控制主库负载)
- [OpenAI：将PostgreSQL伸缩至新阶段 · 关于监控视图语义](/db/openai-pg/#关于监控视图语义)

### 云 RDS 如何束缚 OpenAI，自建赢在哪？ {#cloud-rds-castration-vs-self-hosted}

OpenAI 求助的三大痛点在开源生态早有现成解法：改 `pg_index.indisvalid` 可秒级灰度禁索引，`pg_stat_monitor` 或宿主机 eBPF 可抓分位点延迟，`EVENT TRIGGER` 配扩展能留痕表级 DDL。顶级团队束手无策，纯粹是被 Azure RDS 阉割了 `superuser` 与 OS 权限；基于本地 NVMe 用开源发行版自建即可彻底破局。

- [OpenAI：将PostgreSQL伸缩至新阶段 · 自建 PostgreSQL ？](/db/openai-pg/#自建-postgresql-)

## 三、零停机迁移与平台生产底座 {#live-migration-and-platform}

### “空中换引擎”如何零停机迁移且步步可回滚？ {#zero-downtime-dual-write-migration}

物理复制切主改写后不可无损回退，表级零停机迁移须走“复制、改读、改写”三步：应用先开幂等双写，锁表追平后再切读、切单写；若拆成 8192 分片，逐片锁表仅卡数秒且步步可回滚。严禁用双 `psql` 管道锁表拷大表——实测源端早退 0.1 秒提前放锁必撕裂一致性，未分片大表须按唯一键分批行锁搬运。

- [空中换引擎：PostgreSQL不停机迁移数据 · 一、复制](/pg/migration-without-downtime/#一复制)
- [空中换引擎：PostgreSQL不停机迁移数据 · ETL函数](/pg/migration-without-downtime/#etl函数)
- [空中换引擎：PostgreSQL不停机迁移数据 · 物理复制](/pg/migration-without-downtime/#物理复制)

### 平替微软库与对接 Dify 有哪些基建坑？ {#mssql-babelfish-and-dify-ops}

企业迁移与平台落地成败全在外围生产闭环：用 WiltonDB 平替 SQL Server，须将 1433 端口接入高可用路由与 PITR 监控底座，再配 `pgloader` 一键导数。将 Dify 等容器化 AI 平台对接外部生产 PG 时，须预装 `pgvector` 防越权报错、配妥内网 `no-proxy` 白名单，并将 80 端口收口至统一反代。

- [PostgreSQL可以替代微软SQL Server吗？ · Pigsty v3](/pg/pg-replace-mssql/#pigsty-v3)
- [使用Pigsty自建Dify：AI工作流平台 · 从零开始的一些说明](/pg/dify-setup/#从零开始的一些说明)

### 自建 Supabase 与代理层须补哪些护栏？ {#production-supabase-and-mcp}

生产自建 Supabase 须用超 40 位 `JWT_SECRET` 重签默认密钥，配齐 HTTPS、外部 S3 `pgBackRest` 冷备及三节点以上同步高可用集群。同时正如 Andy Pavlo 所观察，AI Agent 已创建了 Neon 80% 的实例，印证数据库分支是试错刚需；但多数 MCP 只是缺意图内省的裸 SQL 转发器，共用高权限账号极易删库，必须在连接池代理层补上自动化防火墙护栏。

- [自建Supabase：创业出海的首选数据库 · 进阶主题：真·高可用](/db/supabase/#进阶主题真高可用)
- [Andy Pavlo：2025 数据库世界年度总结 · Andy 的看法](/db/db-in-2025/#andy-的看法-1)