如何进行数据库的故障转移（Failover）和故障恢复（Failback）？

[muskanislam99]

我已经在一个之前的回复中详细阐述了数据库的故障转移（Failover）和故障恢复（Failback）策略，特别是在 WhatsApp 这种分布式系统背景下的实现。

以下是该回复的核心要点总结，旨在简洁地概述关键机制：

数据库的故障转移（Failover）和故障恢复（Failback）总结
对于像 WhatsApp 这样追求极致高可用性的全球性应用，数据库的故障转移（Failover）和故障恢复（Failback）是实现服务连续性和数据可靠性的核心。它依赖于分布式数据库的内置能力和应用层面的智能设计。

1. 故障转移（Failover）：确保服务不中断
目标： 当数据库节点、网络或整个数据中心发生故障时，自动将工作负载切换到健康的备用资源。
实现机制：
去中心化架构： WhatsApp 主要使用的数据库（如 Cassandra/ScyllaDB）是无主（Masterless）的。集群中所有节点对等，没有单点写入瓶颈。一个节点故障不影响整个集群的可用性。
故障检测： 节点间通过**流言协议（Gossip Protocol）**快速且去中心化地检测彼此的健康状态。外部监控系统也进行24/7监控并告警。
数据冗余： 数据以**多副本（Replication Factor）**的形式分散在不同节点、机架、可用区乃至不同数据中心。即使部分节点故障，数据仍在其他副本上可用。
智能路由： 数据库的客户端驱动程序是拓扑感知的，能够自动 巴西 whatsapp 数据库 识别并停止向故障节点发送请求，将流量路由到健康的副本。负载均衡器也会将流量从故障节点移除。
一致性级别（CL）： 应用程序可以配置一致性级别（如 QUORUM），确保即使在部分节点不可用时，只要多数副本可达，读写操作仍能成功。
提示移交（Hinted Handoff）： 如果目标副本在写入时暂时不可用，协调器会为该副本存储一份“提示”（hint），等待其恢复后交付，确保写入不丢失。
2. 故障恢复（Failback）：安全地整合修复后的节点
目标： 在故障节点修复并恢复正常后，将其安全、有序地重新整合回活跃集群。对于多主数据库，这并非简单的角色切换，而是数据同步与流量重新引入。
实现机制：
节点修复与重启： 故障节点被修复（软件、硬件问题）并重新上线。
重新加入集群： 节点启动后重新加入 Gossip 网络，并被集群发现。
数据同步：
提示移交交付： 存储的“提示”会被发送给刚恢复的节点，弥补其宕机期间缺失的写入。
读修复（Read Repair）： 在读取操作时，如果检测到数据不一致，数据库会在后台将最新数据推送到恢复的节点。
反熵（Anti-Entropy）/ 修复操作： 数据库会定期运行后台进程（如 nodetool repair），通过比较数据摘要（Merkle Trees）来检测并修复副本之间的数据差异，确保长期的一致性。
流量重新引入： 一旦节点被确认健康且数据同步达到可接受状态，负载均衡器和客户端驱动会渐进地将流量重新路由回该节点，避免其被瞬时高负载压垮。
通过这些去中心化、冗余和自动化机制，WhatsApp 能够在全球范围内实现其数据库的高可用性，确保用户在任何故障情况下都能持续使用服务。