数据库高可用架构搭建运维方案

数据库高可用不是装个双机热备就完事，很多团队把主从复制搭起来就以为高可用落地了，结果切主的时候丢数据、脑裂、连接池不刷新，故障没解决反而把业务拖垮。真正可用的高可用架构，核心要解决三件事：数据一致性怎么保证、故障怎么自动发现和切换、应用层怎么无感或者低感地完成连接切换。脱离这三个问题谈高可用，基本都属于纸上谈兵。

不同业务对可用性的容忍度完全不同。财务、订单、库存类系统要求数据零丢失，RPO必须等于0，RTO尽量控制在秒级；后台报表、日志分析类系统允许丢少量数据，RTO可以放宽到分钟级。架构选型第一步是把业务分级，不要用同一套方案覆盖所有库。常见的架构路线有三条：主从复制加手动或半自动切换、主从复制加自动故障转移、基于一致性协议的真正多主或强一致集群。绝大多数MySQL场景下，主从加高可用管理组件是性价比最高的选择；PostgreSQL可以用Patroni加etcd实现自动选主；对一致性要求极高的场景才考虑Paxos或Raft类方案，比如TiDB、OceanBase或者MySQL Group Replication。

MySQL异步复制是默认模式，主库提交事务后立刻返回，从库可能还没收到binlog。主库宕机时，从库大概率缺最后一部分事务，直接切过去就是数据丢失。半同步复制能缓解这个问题，主库提交前至少等待一个从库确认收到binlog，但半同步在从库超时后会退化成异步，而且主库崩溃时最后一个事务可能已经提交给客户端但还没同步到从库，仍然存在丢失窗口。要真正做到RPO等于0，必须用增强半同步配合从库持久化确认，或者直接上Group Replication这种基于多数派确认的机制。另外主从延迟是常态，大事务、DDL、备份任务都会造成延迟，切换前必须检查从库的延迟状态，否则切过去应用读到旧数据，业务逻辑可能直接错乱。

自动切换组件市面上很多，MySQL阵营常见的有MHA、Orchestrator、MySQL Router配合InnoDB Cluster，PostgreSQL则是Patroni占据主流。MHA部署简单，但已经多年不活跃维护，对MySQL 8.0的新特性支持有限。Orchestrator是目前比较推荐的方案，它的拓扑发现和故障检测机制成熟，支持手动、半自动、全自动三种模式，还能做从库自动修复和中间主库的级联管理。Patroni对PostgreSQL的流复制和逻辑复制支持都很好，配合etcd或Consul做分布式选主，能避免脑裂。无论选哪个组件，有几个配置必须盯死：故障检测超时时间不能太短，网络抖动容易误判；切换前必须做数据补齐，尝试从旧主拉取未同步的binlog；切换后要执行旧主的降级和隔离，防止双主写入。

脑裂发生的原因通常是网络分区导致两个节点都认为自己是主库，或者旧主没被成功隔离又恢复服务。预防脑裂的核心手段是多数派仲裁和fencing机制。多数派仲裁要求集群节点数至少为三，选主时必须获得超过半数节点的投票，这样在分区场景下只有一边能选出新主。fencing则是切换成功后，通过关闭旧主端口、修改旧主只读、或者直接通过管理网络执行关机命令，确保旧主无法继续接受写入。很多团队用双节点加一个仲裁节点的方式，但仲裁节点如果只是简单投票而不参与数据复制，切换后新主的数据完整性依然依赖复制机制，这一点要区分清楚。另外应用层连接池如果没有及时刷新拓扑，旧连接仍然指向旧主，即使旧主已经被降级，写入请求也会报错或者被拒绝，所以切换流程里必须包含连接池刷新或者DNS切换的步骤。

数据库切主之后，应用如果还连旧地址，高可用等于白做。常见做法有三种：VIP漂移、代理层、客户端驱动感知拓扑。VIP漂移最简单，切换时把VIP从旧主解绑并绑定到新主，应用无感知，但VIP漂移本身有秒级到十几秒的生效时间，而且云环境下VIP的灵活性受限。代理层方案比如ProxySQL、MySQL Router、PgBouncer，代理本身要解决高可用问题，否则代理挂了比数据库挂了还麻烦。客户端驱动感知拓扑是最彻底的方案，MySQL Connector/J支持多主机列表和故障转移，PostgreSQL的JDBC驱动也支持多主机和targetServerType参数，应用配置里写多个节点地址，驱动自动识别主从角色。但驱动感知对连接池的配合要求高，很多连接池会缓存连接状态，需要额外配置连接校验和重连策略。实际生产环境里，代理层加连接池的组合最普遍，因为对应用侵入最小，但代理层自身必须做成集群模式。

高可用架构搭建完成后，最大的风险不是组件本身，而是长期不演练导致切换流程生疏、配置漂移、数据不一致积累。建议每季度至少做一次真实切换演练，演练内容包括：模拟主库宕机、模拟网络分区、模拟从库延迟、模拟代理层故障。演练过程中记录切换耗时、数据校验结果、应用报错数量。数据一致性校验工具方面，MySQL可以用pt-table-checksum定期对比主从数据，PostgreSQL可以用pg_checksums或者逻辑复制对比。切换演练中发现的连接池不刷新、序列号冲突、自增ID跳号、触发器未同步等问题，都要形成检查清单固化到运维手册里。很多事故复盘发现，切换失败的原因不是架构设计错误，而是某个参数在几个月前被改过，或者新上线的业务表没有加入复制过滤规则。

高可用架构防的是节点故障，防不了误删除、误更新、勒索软件、机房级灾难。备份必须独立于高可用体系存在，而且要定期做恢复验证。物理备份恢复快但跨版本兼容性差，逻辑备份灵活但恢复慢，两者要结合。全量备份加增量备份的周期根据数据变化量定，核心库建议每天全量加每小时增量，备份文件要同步到异地存储。恢复验证不是简单看备份文件能不能解压，而是要定期把备份恢复到独立的测试环境，跑一遍数据校验和应用冒烟测试。很多团队备份做了几年，真到恢复的时候发现备份文件损坏或者恢复出来的数据缺表缺索引，这种教训代价极大。

数据库监控不能只看CPU、内存、连接数这些基础指标，高可用相关的状态指标更重要。主从复制状态要监控Seconds_Behind_Master、Slave_IO_Running、Slave_SQL_Running、复制错误码；半同步要监控Rpl_semi_sync_master_status和从库确认超时次数；Orchestrator和Patroni要监控集群健康状态、选主事件、拓扑变化。告警阈值要区分级别，复制中断超过30秒必须告警，切换事件必须实时通知，从库延迟超过业务容忍阈值要提前预警。监控数据还要留存历史，用于故障复盘和容量规划。另外高可用组件自身的日志要集中采集，切换失败时能快速定位是选主逻辑问题、网络问题还是数据补齐失败。

云厂商提供的RDS类产品已经内置了高可用能力，但用户仍然要理解其实现机制。云数据库的高可用通常是主备架构加自动切换，跨可用区部署可以防机房级故障，但跨可用区的网络延迟会增加提交时延，半同步或强一致模式下延迟更明显。云数据库的切换窗口、数据丢失量、维护事件通知都需要仔细阅读SLA。自建数据库上云时，不要把本地机房的VIP漂移方案直接搬到云上，云网络不支持传统ARP欺骗式的VIP漂移，要用云厂商的虚拟IP、负载均衡或者代理方案。混合云场景下，跨云高可用涉及网络专线、数据同步延迟、DNS切换，复杂度成倍增加，建议优先考虑应用层双写或者数据同步工具，而不是数据库层直接做跨云复制。

数据库高可用架构的搭建和运维是一个持续迭代的过程，没有一劳永逸的方案。架构选型要匹配业务等级，切换机制要经过真实演练验证，监控告警要覆盖状态机，备份恢复要独立兜底。把这些环节做实，高可用才不是摆设。