数据库高可用（High Availability）是系统架构中最关键的一环，它直接决定了业务能否在故障发生时持续对外提供服务。很多团队在初期设计时只关注主从复制，却忽略了故障切换的细节，导致真正发生宕机时无法自动恢复，甚至出现数据丢失。本文将从实际问题切入，边操作边解释，帮助您掌握高可用架构的核心设计原则和故障切换的实践要点。
主从复制：高可用的基础
主从复制是数据库高可用的最常见的实现方式。它通过将主库（Primary）的变更日志（如MySQL的binlog、PostgreSQL的WAL）异步或同步地传输到从库（Standby），从而保持数据的一致性。在配置时，需要注意以下几点：
- 选择合适的复制模式：异步复制性能好但可能丢失数据，半同步复制在性能和可靠性之间取得平衡，同步复制最安全但影响主库性能。应根据业务对数据丢失的容忍度来选择。
- 监控复制延迟：复制延迟过高会导致从库数据陈旧，故障切换时可能丢失大量数据。应设置监控告警，并定期检查从库的复制状态。
- 确保从库的配置与主库一致：包括参数设置、存储引擎、字符集等，避免因环境差异导致的复制异常。
故障切换：从发现到恢复的完整流程
故障切换（Failover）是指在主库发生故障时，将从库提升为新的主库，并重新路由应用请求的过程。一个完整的故障切换流程包括：
- 故障检测：通过心跳检测或第三方监控工具（如Consul、ZooKeeper）来监控主库的健康状态。检测机制需要避免误判，通常使用多个检测点或加权检测。
- 选主决策：当确认主库故障后，需要从多个从库中选举一个作为新主库。选举策略通常基于数据的新鲜度（如复制偏移量）和从库的优先级。可以使用分布式一致性算法（如Raft）来保证选举的可靠性。
- 数据补全：在提升新主库之前，需要尽量补全旧主库上未复制的数据。如果旧主库仍然可访问，可以尝试获取其最新的binlog，并应用到新主库上。如果旧主库已不可用，则只能接受部分数据丢失。
- 切换路由：将应用的数据库连接从旧主库切换到新主库。这通常通过更新DNS、负载均衡器或数据库代理（如ProxySQL、HAProxy）来实现。切换过程中应尽量减少对应用的影响，例如使用连接池的自动重连机制。
脑裂问题：高可用架构的最大威胁
脑裂（Split Brain）是指由于网络分区，集群中的多个节点都认为自己是主节点，导致数据写入冲突和系统不一致。这是高可用架构中最严重的问题之一。防止脑裂的常见方法包括：
- 使用仲裁机制：引入第三方仲裁节点（如ZooKeeper、etcd），当主节点无法与仲裁节点通信时，自动降级为从节点，避免同时出现多个主节点。
- 设置法定人数（Quorum）：在集群中要求多数派节点同意才能选主，确保只有一个主节点。例如，在3节点的集群中，至少需要2个节点同意才能选主。
- 启用fencing机制：当新主节点被选出后，通过物理或逻辑方式隔离旧主节点，例如关闭其网络接口或将其从集群中移除，防止旧主节点继续写入。
日志与监控：高可用架构的基石
日志和监控是确保高可用架构可靠运行的关键。正如OWASP日志安全速查表所述，应用日志应包含安全事件，并保持一致性，以便被广泛系统消费、关联和分析。在数据库高可用中，日志的作用尤为重要：
- 记录故障切换的完整过程：包括故障检测时间、选主决策、数据补全情况、切换结果等，便于事后审计和问题排查。
- 监控复制状态：通过日志监控复制延迟、错误、中断等，提前发现潜在风险。
- 审计访问行为：记录数据库的访问日志，辅助安全分析。
OpenTelemetry日志规范指出，日志是遥测信号中历史最悠久的，需要与现有日志库和收集系统兼容。在数据库高可用架构中，我们可以利用OpenTelemetry来统一收集和分析数据库日志，实现更全面的可观测性。例如，通过OpenTelemetry Collector采集数据库的慢查询日志、错误日志，并关联到分布式追踪，从而快速定位问题。
配置示例：以MySQL半同步复制为例
下面以MySQL为例，演示如何配置半同步复制和故障切换的常用步骤。请注意，具体命令可能因版本而异，请在测试环境验证后再应用到生产。
- 安装半同步插件：在主库和从库上安装半同步插件，并在主库启用半同步复制。
- 配置复制用户：在主库创建复制专用用户，并授权。
- 设置从库：在从库上设置主库信息，并启动复制。
- 启用自动故障切换：使用MHA（Master High Availability）或Orchestrator等工具，配置监控和自动切换。
在配置过程中，需要注意：
- 半同步复制在超时后会降级为异步，需要合理设置超时时间。
- 自动故障切换工具需要配置好仲裁和fencing，避免脑裂。
- 在切换前，务必进行演练，确保流程可靠。
验证与演练：确保万无一失
高可用架构不是配置完就万事大吉，必须定期进行故障演练，验证切换流程的有效性。演练内容包括：
- 模拟主库宕机：通过kill主库进程或断网，观察系统是否自动切换，切换时间是否符合预期。
- 验证数据一致性：在切换后，检查数据是否完整，是否有丢失。
- 检查应用恢复：确认应用能自动重连到新主库，业务恢复正常。
演练过程中应记录所有日志，并分析切换中的每个环节，持续优化。
常见误区与注意事项
- 误区一：只做主从复制，不做自动切换。主从复制只是数据备份，不能自动恢复服务，必须配合自动故障切换机制。
- 误区二：忽略复制延迟。复制延迟过高会导致切换时丢失大量数据，应实时监控并设置阈值。
- 误区三：不配置fencing。没有fencing机制，脑裂风险极高，必须确保旧主节点被隔离。
- 注意事项：高可用架构涉及网络、存储、应用等多个层面，需要综合考虑；同时，不同数据库（如MySQL、PostgreSQL、MongoDB）的高可用方案各有差异，应根据具体场景选择。
参考资料
延伸阅读