数据库高可用需架构设计、组件协同与运维策略共同保障，核心是主库故障时秒级/分钟级自动切换、不丢数据、应用无感知；常用主从复制+自动故障转移方案，如MySQL的MHA、PostgreSQL的Patroni；须跨机房部署、启用同步复制、避免脑裂、自动更新应用连接；多活慎用，备份恢复是底线，需定期演练；监控告警与持续压测不可或缺。
数据库高可用（High Availability, HA）不是靠单个功能实现的，而是通过架构设计、组件协同和运维策略共同保障服务持续可访问。核心目标是：主库故障时，能在秒级或分钟级内自动或半自动切换到备用节点，且不丢数据、不乱序、应用无感知或影响极小。
主从复制 + 自动故障转移
这是最常用、成本可控的基础方案。MySQL 常用 MHA、Orchestrator 或官方 InnoDB Cluster；PostgreSQL 多用 Patroni + etcd + Streaming Replication。
- 至少部署一主两从（建议跨机房/可用区），从库开启 同步复制（如 MySQL 的 semi-sync、PostgreSQL 的 synchronous_commit = 'remote_apply'），避免主库宕机丢失已提交事务
- 使用轻量级探活+仲裁机制（如 Patroni 依赖 etcd 投票、MHA 依赖 SSH 和 manager 节点），避免脑裂；禁止纯 ping 心跳判断主库存活
- 切换后需自动更新应用连接配置（通过 VIP 漂移、DNS 切换或中间件路由，如 ProxySQL、ShardingSphere-Proxy）
多活架构（Active-Active）慎用但有场景价值
适用于地域分散、读写均需本地低延迟的业务（如跨国 SaaS），但复杂度高、一致性风险大，不推荐中小团队直接采用。
- 逻辑上分片（Sharding）是前提，同一份数据只在一个中心写入，避免双向同步冲突
- 若真需多点写入，必须引入冲突检测与解决机制（如基于时间戳/向量时钟 + 应用层合并逻辑），或选用原生支持多活的数据库（如 CockroachDB、TiDB 默认强一致多副本）
- 跨中心延迟不可控，需接受最终一致性，并在应用层做幂等、补偿、状态回查
备份与恢复能力是 HA 的底线保障
自动故障转移解决的是“短时中断”，而备份恢复决定能否从误删、逻辑错误、勒索攻击中真正存活。
- 每天全量备份 + 每15–30分钟归档 WAL/binlog，保留至少7天，异地保存一份
- 定期执行恢复演练（每月至少一次），验证备份有效性及 RTO/RPO 是否达标
- 关键业务表启用行级 Flashback（如 MySQL 8.0+ 归档日志插件、PostgreSQL pg_dirtyread 或逻辑复制槽回拉），加速小范围误操作修复
监控、告警与可观测性不能缺位
没有监控的 HA 是盲人骑马。重点盯住：复制延迟、主从状态、连接数突增、慢查询积压、磁盘 IO 饱和、WAL 发送/接收延迟。
- 设置分级告警：延迟 > 5 秒发企业微信/钉钉；延迟 > 60 秒或主库不可达立即电话升级
- 在应用端埋点采集数据库响应时间、失败率、重试次数，与 DB 层指标交叉分析，快速定位是 DB 问题还是应用滥用（如未走索引、循环查库）
- 所有切换操作留痕（谁、何时、触发原因、执行命令、结果），便于事后复盘
不复杂但容易忽略：高可用不是上线就完事，它需要持续压测（模拟主库 kill -9、网络分区）、定期切流演练、配置版本管理（Ansible/Terraform 管理集群定义），以及明确的降级预案（比如切到只读、降级缓存兜底）。
