最近公司数据库服务器崩盘后，我蹲在机房啃着冷掉的烧饼时突然想到——该聊聊高可用架构这个保命技能了。市面上各种技术让人眼花缭乱，今天咱们就掰开PostgreSQL的流复制和Patroni这对冤家，看看什么场景该选谁，以及怎么做灾备才能让我们凌晨三点不被警报叫醒。
一、生死关头的基础装备：流复制实战手册
先给小白举个真实案例：去年双十一某电商公司因为主库宕机，硬是手动切换备库花了20分钟，损失了八个零的订单量。咱们用PostgreSQL 14的流复制作个保底方案：
wal_level = replica
max_wal_senders = 5
# 备库配置 recovery.conf（现版本改为在postgresql.conf中配置）
primary_conninfo = 'host=192.168.1.100 port=5432 user=replicator password=secret'
standby_mode = on
# 创建复制专用账号（主库执行）
CREATE ROLE replicator WITH REPLICATION LOGIN ENCRYPTED PASSWORD 'secret';
这个配置就像给数据库买了意外险，但是有两个坑需要注意：当主库宕机时，备库不会自动上位，得手动pg_promote()；同步复制如果备库卡顿，主库写入都会被阻塞。去年我们团队就遇到过客服系统因备库IO性能不足导致整个服务卡死的情况。
二、智能管家Patroni的生存之道
还记得去年春节值班时，隔壁组小哥因为误操作导致主备切换失败的事故吗？现在上Patroni（基于Python 3.8+和PostgreSQL 14）这种自动化管家就靠谱多了：
# patroni.yml 配置片段
scope: pg-cluster
restapi:
listen: 0.0.0.0:8008
etcd:
hosts: "etcd1:2379,etcd2:2379"
bootstrap:
dcs:
ttl: 30
retry_timeout: 10
initdb:
encoding: UTF8
pg_hba:
- host replication replicator 192.168.1.0/24 md5
- host all all 0.0.0.0/0 md5
实测当主库突发宕机时，Patroni能在5秒内完成故障转移。但别高兴太早，去年我部署时踩过分布式锁的坑——ETCD集群网络抖动导致出现"双主"现象，后来发现必须保证时钟同步误差在50ms以内。
三、现实版攻防演练（技术栈：PostgreSQL 14+Patroni 2.1）
模拟某在线教育平台的真实环境：1主2备+ETCD集群，突发主节点机房断电：
# 手动触发切换测试
patronictl switchover --master pg-node1 --candidate pg-node2 --force
# 查看集群状态
patronictl list
+ Cluster: edu-platform (6891577549637458976) -----+----+-----------+
| Member | Host | Role | State | TL | Lag in MB |
+----------+-------------+---------+---------+----+-----------+
| pg-node1 | 192.168.1.1 | Replica | running | 5 | 0 |
| pg-node2 | 192.168.1.2 | Leader | running | 5 | |
| pg-node3 | 192.168.1.3 | Replica | running | 5 | 0 |
+----------+-------------+---------+---------+----+-----------+
这场景暴露一个关键问题：当备用节点数据延迟超过容忍阈值时，Patroni会拒绝提升。今年三月某券商系统就因此未能自动切换，后来我们在配置中添加了maximum_lag_on_failover: 100才解决。
四、高手选装备的军规
流复制使用场景：
适合预算有限的中小型项目，像社区医院的HIS系统，每天几百个门诊量级别的数据规模。今年帮某县医院部署时发现，他们的单备库异步复制已足够，但必须配合crontab监控脚本。Patroni决胜时刻：
处理秒杀系统这种需要7*24稳定的场景。去年某直播平台的礼物系统用Patroni集群扛住了百万并发，不过需要注意调整ttl参数平衡故障检测速度与网络抖动容忍度。隐藏陷阱清单：
- 异步流复制可能丢失最近10秒数据（去年物流公司因此丢过运单）
- Patroni需要至少3节点的ETCD/Consul（创业公司初期可先用ZooKeeper临时方案）
- 物理流复制与逻辑复制的混合使用会导致冲突（上个月踩过这个坑）
监控生死线：
必须要用Prometheus配Alertmanager，特别是pg_replication_lag这个指标。记得设置梯度报警：超过100MB发微信，超过1GB打电话。
五、灾备方案设计四象限
根据项目规模选策略：
微型项目套餐：
主库+异机异步备库，每天凌晨用pg_basebackup做全量备份，成本两杯奶茶钱。企业标配方案：
Patroni集群+pgbackrest自动归档（某互联网金融公司用这套实现了RPO<5s）土豪专享版：
跨区域多活架构，去年某全球游戏公司用Citus+Patroni实现五大洲节点同步，烧钱但确实靠谱。亡羊补牢包：
建立延迟归档机制（保留三天前的WAL日志），上个月我们团队用这招从被黑的数据库中抢救回了70%数据。
六、血泪总结：八年DBA的忠告
流复制像手动挡汽车，适合老师傅慢慢把玩；Patroni就是自动驾驶，但需要定期保养。最关键的是：
- 千万别在生产环境直接试新配置（血的教训）
- 灾备方案必须每月演练（某银行因没做这个被监管处罚）
- 文档永远比记忆可靠（别问我是怎么知道的）
评论