摘要：数据库一宕机，损失的不只是数据，更是信任。今天，我们从高可用的核心概念讲起，梳理从单机到多副本的演进路径，再结合 KaiwuDB 五种高可用方案，帮你快速判断哪种方案适合你的业务场景。

一、数据库宕机，信任的破产

数据库宕机是每个团队都不愿面对的场景。系统卡死、应用报错、客服电话被打爆------做后端或者 DBA 的人对此都不陌生。宕机一个小时的损失，对中小企业是数万元，大型平台则动辄百万级别。数据库高可用（High Availability），本质上就是让系统在硬件故障、网络抖动、机房断电等异常情况下，仍然能够持续对外提供服务。这不是锦上添花的功能，而是生产系统的基本要求。衡量高可用有两个核心指标：

• RPO（Recovery Point Objective）表示能容忍丢失多少数据，RPO 为 0 意味着数据零丢失。

• RTO（Recovery Time Objective）表示恢复需要多长时间，RTO 10 秒意味着故障后 10 秒内必须恢复服务。

不同场景对这两个指标的要求差异很大------金融交易必须 RPO 为 0，物联网传感器采集场景则可以容忍几秒的数据丢失。这意味着高可用方案的选择必须回到业务场景本身。把可用性做到 99.99%，对应全年宕机时间不超过 53 分钟。做到 99.999% 则是 5 分钟。这个目标对大多数团队来说并不轻松，尤其当系统存在多个下游依赖时。而且，高可用和一致性之间也存在内在矛盾。根据 CAP 理论，分布式系统在网络分区时需要在可用性和一致性之间取舍。KaiwuDB 选择了 CP 路线，优先保证数据强一致性，同时通过 RAFT 协议快速恢复可用性，避免出现部分节点数据一致、部分节点不一致的情况。

二、从"手挡"到"自动驾驶"的演进之路

数据库高可用的实现方式也经历了一个演进过程：

最早是单机架构，所有数据存放在一台服务器上，硬件故障即意味着服务完全中断，就像一辆只有前进挡的车，一旦抛锚就只能彻底趴窝，如今生产环境很少采用。

随后出现的主备复制模式，由一台主库提供服务、一台备库同步数据，主库故障时需要手动切换至备库。这种方案成本低但切换期间服务不可用，RTO 通常在分钟级别，好比手动挡汽车换挡需要人工踩离合操作，目前仍有许多中小公司采用。

再后来是双活和多活架构，多台机器同时对外服务，单点故障时流量自动切换至其他节点，可用性显著提升，但对底层一致性协议的要求也更高，类似于自动挡的平顺过渡，无需人工干预换挡。

当前的主流方案是多副本加分布式共识协议------数据在多个节点保留多份副本，通过 RAFT 或 Paxos 等协议实现自动选主和故障转移，在保证强一致性的同时实现自动化切换。这就好比进入了自动驾驶阶段，系统能够智能感知故障并自主完成决策与恢复，KaiwuDB 采用的就是这一路线。

RAFT 与传统主备方案的关键区别在于，它不存在固定的主从关系，任何一个副本都可能通过投票成为主副本。实现工业级稳定的 RAFT 协议并不简单，不同产品在工程实现上的质量也存在差异。高可用方案的选择本质上是在成本、一致性和恢复速度三者之间做权衡，不存在普适的最优解，只有最适合当前业务场景的方案。

三、KaiwuDB 4 种高可用方案

KaiwuDB 提供了丰富多样的高可用方案。接下来按照部署模式分别介绍4种实用方案：

• 集群部署场景优选：多副本集群高可用、集群复制

• 单点部署场景优选：基于 WAL 高可用、基于 DRBD 高可用（专为物联网场景设计）

方案	说明	部署模式	最小节点数	故障转移	典型场景
多副本集群高可用	基于 RAFT 协议保证数据强一致性，单节点故障自动选举主副本，无需人工干预。	集群	3	自动	同数据中心多节点生产部署
集群复制	异步复制机制，支持表级和库级复制粒度，具备断点续传能力。	集群（主备各一套）	6	手动	跨数据中心灾备、一主多备
基于 WAL 的主备复制	KaiwuDB 原生能力，通过内置 SQL 命令管理主备生命周期，RTO < 10 秒，硬件成本低。	单节点	2	手动	资源受限、需快速切换的单节点部署
基于 DRBD 的主备复制	基于 DRBD + Pacemaker 开源方案，故障时自动完成资源漂移和服务切换，适合无人值守场景。	单节点	2	自动	物联网场景自动切换

方案1：多副本集群高可用

KaiwuDB 的主打方案，能够实现故障转移和数据强一致性。集群中的各节点通过定期的心跳机制维护连接和状态，可以及时发现故障并采取相应措施。KaiwuDB 多副本集群默认采用 3 副本机制，通过 RAFT 协议保证数据一致性和可用性，因此至少需要 2 个副本保持可用状态。今天我们以 5 节点集群为例，来介绍下 KaiwuDB 多副本集群的大概运行机制。KaiwuDB 集群启动后，分片副本均匀分布在所有节点上，确保数据的高可用性和负载均衡。

情况1：单节点故障

单个节点离线后，如果该节点存在某分片的主副本，系统会自动从该分片在其他节点上的副本中重新选出新的主副本，以确保数据服务的连续性及数据一致性。在主副本重新选举期间，集群可以正常提供服务，DDL 和 DML 操作均可正常执行。对于查询操作，只有当正在执行的查询语句涉及故障节点时，该语句才会执行失败。此时应用可以立即重新发起查询，系统能够正常响应并提供服务。

节点离线超过 1 分钟后，系统会将其标记为异常节点。节点离线时间达到设定值（默认为 30 分钟）后，系统会将该节点标记为不可用节点。当剩余节点数量仍大于副本数时（例如剩余 4 节点但副本数为 3），系统会自动补足缺失的副本，确保数据高可用性。副本补足期间，数据查询、DDL 和 DML 操作均不受影响。用户也可通过相关参数关闭副本自动补足功能，在系统负载较低时重新启用。

如果之前通过 CONFIGURE ZONE 语句设置了副本约束，且约束规则中包含异常节点，可能会影响副本补足功能的正常运行。此时需要重新配置约束规则，将异常节点从规则中移除，副本补足功能即可恢复正常。

异常节点或不可用节点恢复后，系统会自动进行数据同步或数据补齐。节点恢复期间，数据查询、DDL 和 DML 操作均不受影响。

情况2：多节点故障

依次故障

如果两个节点依次发生故障，当第二个节点故障前系统已完成副本补足，则第二个节点故障后，系统仍可正常运行。注意：在 5 节点三副本集群中禁用副本自动补足功能后，将无法承受连续的节点故障。

同时故障

如果两个或更多节点同时出现故障，由于剩余节点数小于或等于副本数，系统无法补足缺失的副本，可能导致部分数据无法访问，甚至出现集群无法使用的情况。

详细说明可前往 >>https://www.kaiwudb.com/docs/#/v3.2.1/best-practices/single-ha-drbd.html

方案2：集群复制

KaiwuDB 集群复制是一种异步数据同步机制，支持将表或库的数据（包括时序数据和关系数据）从主库（源端）集群实时复制到备库（目标端）集群，实现主备部署和灾备能力。用户可通过启动/停止复制任务来管理数据同步，并基于复制状态监控实现主备切换和灾备恢复。具备以下灵活的特性：

• 灵活的复制粒度：支持表级别和库级别的数据复制。库级别复制定义后，表内数据、新增表及对应 DDL 操作均自动复制。

• 断点续传：支持从指定时间点开始历史数据复制和断点续传。复制中断后，系统会基于上次 checkpoint 恢复复制，无需从头开始。

• 高可用性：在多副本架构下，故障节点数小于副本数的一半时，复制仍可正常进行。主库节点故障时，RangeFeed 会自动切换到新的 leader 节点继续推送数据；备库节点故障时，复制协程会重新选举并从上次 checkpoint 恢复。网络中断时，系统会自动重试连接，通过 HAProxy 代理切换到可用节点，并基于断点继续复制。

集群复制适合以下场景：

• 集群主备部署：在同一数据中心内部署主备集群，主库承担业务读写负载，备库实时同步数据。当主库发生故障时，可以快速将业务切换到备库，保障业务连续性。

• 跨数据中心灾备：在不同地理位置的数据中心间建立主备复制关系，实现异地容灾。当主数据中心发生重大故障、自然灾害或网络中断时，可将业务快速切换到备用数据中心，保障数据安全和业务连续性。

• 一主多备：一个主库同时向多个备库复制数据，实现多份数据备份。不同备库可服务于不同场景：生产环境备份、测试环境数据同步、报表查询负载分离等，提高资源利用率。

• 云边端协同：在云端、边缘节点和终端设备之间建立数据复制关系，支持边缘计算场景。边缘节点采集的数据可实时同步到云端进行集中分析，实现云边数据协同。

详细介绍请前往 >>https://doc.kaiwudb.com/template_version/pc/doc/v3.2.1/db-operation/ha/cluster-replicate.html

方案3：基于 WAL 的高可用性

如果是单点部署场景，KaiwuDB 支持通过基于 WAL（Write-Ahead Logging）日志的主备复制机制实现高可用能力：主库将数据变更（DML）与模式变更（DDL）实时记录至 WAL 日志，备库在拉取日志后，对 DML 执行高效并行回放，对 DDL 执行串行原子回放，在保障数据严格一致的前提下，显著提升主备同步的性能与可靠性。

相比多副本集群的高可用功能，主备复制仅需两台服务器即可完成高可用配置，在降低硬件成本的同时保持较高的数据写入性能。用户可通过配置主备角色，灵活管理主备复制服务的生命周期，包括启动、暂停、恢复和删除等操作。启用主备复制后，主库支持读写操作，备库仅支持读操作，不支持预测分析设置和集群参数配置。

备库发生故障时，主库的读写操作可正常进行，不会影响用户业务。主库发生故障后，用户可手动将备库切换成主库，待主库恢复后重新建立主备关系，也可以将备库转为普通节点，进行数据读写。KaiwuDB 主备复制支持完整的关系数据复制和时序数据复制，包括：

• 显示/隐式事务场景

• DDL/DML 混合场景

• prepare/非 prepare 场景

• 通过 JDBC 协议写入的数据

主备复制实现以下性能目标：

• 计划内主备切换：恢复时间目标（RTO）< 10 秒，恢复点目标（RPO）= 0（无数据丢失）。

• 计划外主备切换：RTO < 10 秒，RPO < 30 秒。

使用说明：

• KaiwuDB 采用异步复制方式，备库数据可能存在一定延迟。

• 在以下情况下执行主备复制相关操作时，系统响应时间可能较长：

  • 主库存在大量历史数据需要复制

  • 混合执行 INSERT、DELETE、UPDATE 及 DDL 语句

  • 执行跨多表的高并发单条写入操作

特殊场景说明：

• 导入导出复制：导入导出的复制要求主库和备库的导入导出路径保持一致。如果主备库导入导出位置不同，需按以下顺序操作：

  1. 停止复制进程

  2. 将 CSV 文件复制到备库的导入导出目录

  3. 在主库执行导入数据操作

  4. 重新启动复制进程

• 随机函数复制：主库执行包含 random() 函数的插入操作时，备库会重新生成随机数据，而不是复制主库生成的随机值，导致主备库数据不一致。建议在需要保持主备一致的场景中避免使用随机函数。

• 物化视图并发写入：在创建物化视图过程中，如果对原始表进行并发的 INSERT 操作，可能导致主备库物化视图数据不一致。此时需要在主库手动执行物化视图刷新以确保主备一致：

-- 在主库执行刷新语句保证主备一致
REFRESH MATERIALIZED VIEW [IF EXISTS] <view_name>;

详细说明可前往 >>https://www.kaiwudb.com/docs/#/v3.2.1/db-operation/ha/single-ha.html

方案4：基于 DRBD 的高可用性方案

这是KaiwuDB专为物联网业务场景设计的高可用方案，用来支持当发生硬件故障或者停机维护时，能够快速切换到备机，保证业务持续运行，不间断地接收设备上传的数据，持续监控设备运行情况。

DRBD（Distributed Replicated Block Device）分布式复制块设备是一种基于软件的无共享复制存储解决方案，用于复制主机之间的块设备（硬盘、分区、逻辑卷等）的内容。DRBD 镜像数据具有以下特点：

• 实时：应用程序修改设备上的数据时，复制将连续进行。

• 透明：应用程序无需关心数据存储在多个主机上的细节。

• 同步或异步：DRBD 提供同步和异步两种复制模式。在同步模式下，只有所有连接的主机都完成写操作后，应用程序才会收到写完成的通知。在异步模式下，本地完成写入时（通常在镜像数据传输到其他节点之前）应用程序就会收到写完成的通知。

KaiwuDB 单节点部署支持采用基于 DRBD 块设备复制的开源软件方案，可以实现主备节点间的数据复制。但由于 KaiwuDB 的单节点部署高可用性方案目前主要关注机房内单台设备故障时，如何利用备机尽快恢复运行，保障系统整体的连续可用，对于异地灾备的需求较少。在设计基于块设备复制的高可用性方案时，建议优先考虑使用同步复制协议来保障数据的一致性。

此外，此方案使用 Pacemaker 方案用于监控运行状态，进行健康检查。Pacemaker 方案是 Linux-HA 工程的一部分，也是目前最成功开源高可用项目之一。Pacemaker 方案通过心跳服务和集群通信两项关键技术，构建了一个高可用集群，能够监控集群中各类资源的状态，执行实例漂移、主备切换等多种功能。KaiwuDB 基于 DRBD 的高可用性方案架构如下图所示：

方案技术重点如下：

• 在主备节点各使用一个容量相等的块设备，用于 DRBD 主备复制。

• 主备节点的安装部署应保持完全一致，包括用户数据目录（即安装部署时指定的 data_root 目录）。

• 将 DRBD 设备挂载到用户数据目录，通过 DRBD 复制软件进行数据同步复制。

• CA 证书等文件由于未存放在用户数据目录中，需要从主节点手工同步至备节点（非安全部署方式无需执行本步骤）。

• 使用 systemd 服务来管理 KaiwuDB 的启动和停止操作。

• 将 DRBD 设备、文件系统及 systemd 服务等资源统一定义在 Pacemaker 集群软件中，通过 Pacemaker 进行状态监控和管理。

详细介绍请前往 >>https://www.kaiwudb.com/docs/#/v3.2.1/best-practices/single-ha-drbd.html

写在最后

数据库高可用没有唯一的答案。理解业务对 RPO 和 RTO 的真实需求，评估不同方案在成本、一致性和恢复速度之间的取舍，比寻找"最佳方案"更有意义。上述介绍的 KaiwuDB的4种方案覆盖了从单节点到跨数据中心的全场景，核心的多副本集群方案基于 RAFT 协议实现了数据强一致性和自动化故障转移，大家按需选择就好。

企业版和开源版均开放了高可用功能，欢迎大家来免费体验试用，点击获取安装包https://www.kaiwudb.com/download?tab=1

KaiwuDB 技术社区欢迎每一位感兴趣、有需求的开发者------来聊聊你遇到过的宕机故事，让我们一起把系统做得更稳一点。

附：本文涉及概念总表

概念	描述
数据分片（Range）	KaiwuDB 将所有用户数据（表、索引等）和几乎所有系统数据存储在键值对的排序映射中。这个键空间被划分为多个数据分片，每个键始终可以在单个数据分片内找到。数据分片是集群高可用性和数据迁移的最小单元。
副本（Replica）	每个用户数据分片默认有 3 个副本，以保证高可用性。数据迁移时，以分片副本为单位进行迁移。
主副本（Leaseholder）	每个分片的主副本，负责处理该分片的读写请求。主副本通过 RAFT 协议选举产生，确保数据一致性。
节点状态	KaiwuDB 中的集群节点存在以下状态：- 存活节点：默认节点状态，表示节点正常运行 - 异常节点：1 分钟内无网络连接的节点会被标记为异常节点 - 不可用节点：默认 30 分钟内无网络连接的节点将被标记为不可用节点，触发数据副本补足机制 提示: 用户可通过 KaiwuDB 监控平台、kw-status 或 kwbase node status 命令查看集群内的节点状态"
主库(源端)	数据复制的源头集群，提供数据给备库
备库(目标端)	数据复制的接收端集群，从主库接收数据
复制任务 ID	系统分配的任务标识符，包括 replication_producer_id（主库任务 ID）和 replication_consumer_id（备库任务 ID）
检查点	记录复制进度的时间点，last_checkpoint 保证该时间点前的数据已复制完成，但因数据入库存在延迟，备库中可能存在入库时间晚于该时间点的数据
断点续传	从中断点继续复制，避免从头开始，基于 last_checkpoint 恢复复制
复制状态	复制任务的执行状态，包括 running（运行中）、paused（已暂停）、succeeded（成功完成）、failed（失败）
RangeFeed	KaiwuDB 的数据变更推送机制，用于实时推送数据变更到备库。集群复制功能依赖此机制，使用前必须在主库通过 SET CLUSTER SETTING kv.rangefeed.enabled = true 启用
HAProxy	高可用代理服务，用于负载均衡和故障切换，建议将复制连接配置为 HAProxy 地址
GC	垃圾回收，清理历史版本数据
RTO	系统从停机恢复到可提供服务的时间。例如，RTO = 0 表示业务不受影响；RTO = 1 分钟表示最长中断 1 分钟。
RPO	停机期间可能丢失的数据量（以秒为单位）。例如，RPO = 0 表示无数据丢失；RPO = 1 秒表示最多丢失 1 秒数据。