数据库高可用与备份演练

应用层 HA 容易，数据层难

无状态服务多副本几乎免费——但数据库：

每一步都要小心翼翼。

写 → Primary
读 → Primary 或 Replica
故障 → 手动/自动 把 Replica 提升为 Primary

主流方案：

托管服务（AWS RDS / Cloud SQL / 阿里 RDS / 腾讯 CDB）默认做了主从——几乎不用自己搞。

Primary
  ├── Replica 1（同区）
  ├── Replica 2（同区，HA）
  └── Replica 3（异区，灾备 / 读分流）

读写分离：写打 Primary，读分散到 Replica——但要接受 replica 滞后（异步复制 → 几毫秒到几秒延迟）。

工具：

工具	数据库	备注
Patroni	PostgreSQL	业内事实标准，基于 etcd / Consul
repmgr	PostgreSQL	开源老牌
Orchestrator	MySQL	GitHub 出品，已捐给 OpenArk
MySQL Group Replication / InnoDB Cluster	MySQL	官方多主方案
托管服务自带	各家 RDS	几次点击启用

⚠ 自动 failover 有自身风险：脑裂（split-brain）—— 网络分区时两边都以为自己是 master，写入冲突。Patroni 等用分布式锁（etcd）避免这个。

数据规模超过单机能扛 → 切分到多台。两种维度：

水平分片复杂得多——应用层要知道"这条数据在哪个分片"。常用工具：

多数公司不需要分片——单机 + 主从扛 99% 业务。考虑分片前先问："是不是某些查询不优化导致以为单机不够？"

生产数据库至少要 PITR——单纯每日全量丢失窗口太大。

每个季度强制做一次：

# 1. 拉一份生产备份到隔离环境
# 2. restore 看耗时
pg_restore --dbname=test_restore backup.dump
# 3. 跑应用 / 测试关键路径
# 4. 看数据完整性（对账）

如果发现：

演练就是为了发现这些，平时不练真出事时 100% 出洋相。