Patroni 是什么
一句话总结
PostgreSQL 的高可用方案——主库挂了自动选新主，整个过程不用人碰，应用端几乎无感。
🤔 为什么会有它 / 解决了什么问题
PostgreSQL 内置的流复制（Streaming Replication）能让你搞一主一备，但主库宕机后不会自动切换——得靠 DBA 半夜起来手动跑命令。而且”谁是主”这个信息没有统一的地方查，应用不知道该连哪个 IP。Patroni 就是解决了这个问题：它用分布式一致性存储（etcd/Consul/ZooKeeper）记录”当前主库是谁”，主库挂了自动触发选主（Leader Election），把备库提升为新的主库，同时更新集群状态让所有人知道新主是谁。
🔍 具体原理 / 运作逻辑
每台数据库服务器上跑一个 Patroni 进程（Python 写的），它通过 etcd 的分布式锁（Leader Key）确定谁是当前主库。主库挂了后 etcd 的锁过期，备库们发起竞选，最先拿到 etcd 锁的备库把自己提升为主库并开始接受写请求。应用不直接连 PostgreSQL IP，而是连 Patroni 的 REST API 或负载均衡器（如 HAProxy），Patroni 告诉它”当前主库是哪个”。
更硬核的技术细节（点击展开）
Patroni 使用 PostgreSQL 的 Streaming Replication 协议做同步，支持同步复制（同步提交保证不丢数据但延迟更高）和异步复制。etcd 用 Raft 共识算法保证分布式锁的可靠性。切换时 Patroni 会把旧主降级为备库，新备库自动从新主流复制。支持 Switchover（计划内切换，零停机）和 Failover（计划外，可能丢少量异步复制未传的数据）。Patroni 本身不处理负载均衡，通常配合 HAProxy 或 PgBouncer 使用。
🧭 什么情况下会用到 / 什么场景会遇到它
- PostgreSQL 跑在生产环境，需要自动故障转移不能依赖 DBA 手动操作
- 数据库集群需要读写分离（主库写、备库读查询）
🛠️ 怎么上手 / 在哪操作
在 PostgreSQL 集群的每台机器上装 Patroni + etcd/Consul，写 patroni.yml 配置，systemd 启动。
⚖️ 副作用 / 代价 / 取舍
- 需要额外维护 etcd 或 Consul 集群（本身也是分布式系统，有自己的运维复杂性）
- 异步复制模式下故障切换可能丢几秒数据（主库已写但备库还没同步的事务）
- Python 写的，在某些极端场景下性能不如 C/Rust 实现的管理工具
- 切换期间写操作会短暂中断（几秒到几十秒，取决于 etcd 检测 + 选主时间）
🕰️ 来历
- 谁提出/创造的：Zalando（欧洲电商公司）开源，由 Alexander Kukushkin 等工程师开发
- 什么时候出现的：2015 年开源发布
🔗 关联 / 经常一起出现的概念
- etcd：Patroni 依赖的分布式键值存储，用来记录集群状态和实现 Leader Election（用 Raft 共识）
- PostgreSQL Streaming Replication：Patroni 底层的数据库复制技术，主库把 WAL 日志实时传给备库
- HAProxy：常和 Patroni 搭配的负载均衡器，把写请求路由到主库、读请求分发到备库
⚠️ 注意事项 / 常见误区
Patroni 不等于”数据库完全不怕挂”。它的切换不是即时的（通常 10-30 秒），而且异步模式下会丢数据。同步复制模式不丢数据但写入变慢。另外很多人以为 Patroni 能自动解决脑裂——不完全，网络分区（Network Partition）场景下可能出现多主同时写入，需要 etcd 的租约机制和合理配置来缓解。
📎 记忆锚点
“PG 的自动换胎系统——主胎爆了备胎自己顶上，不需要你下车操作。”
📝 更新日志
| 日期 | 改动 | 原因 |
|---|---|---|
| 2026-07-13 | 首次创建 | - |