KaiwuDB 运维实战 03：双副本仲裁节点部署与高可用实践

本文面向数据库运维工程师和架构师，承接上篇对双副本仲裁方案的概念介绍，聚焦 KaiwuDB 双副本仲裁节点的实战部署与故障处理。内容基于 KaiwuDB V3.2.x，覆盖仲裁节点初始化、双副本策略启用、扩缩容操作及单节点故障场景演练。

文章目录

[一、 KaiwuDB 双副本仲裁节点设计思路](#一、 KaiwuDB 双副本仲裁节点设计思路)
- [1、高可用不是"要不要"，而是"怎么选"](#1、高可用不是"要不要"，而是"怎么选")
- 2、分布式共识协议的"多数派"代价
- [3、在成本与可靠性之间找平衡点](#3、在成本与可靠性之间找平衡点)
[二、KaiwuDB 双副本仲裁方案核心设计](#二、KaiwuDB 双副本仲裁方案核心设计)
[三、KaiwuDB 双副本仲裁节点部署](#三、KaiwuDB 双副本仲裁节点部署)
- 部署前准备
- - 1、节点规划与硬件要求
  - 2、环境配置
- 集群初始化与仲裁节点加入
- 启用双副本策略
- - 1、全局启用
  - 2、按数据库启用
- 扩缩容操作
- 故障演练：单节点故障
- [监控与 RPO 配置](#监控与 RPO 配置)
- - [1、RPO 配置](#1、RPO 配置)
  - 2、查看节点状态
  - 3、关键监控指标
[常见问题 FAQ](#常见问题 FAQ)
- [Q1：KaiwuDB 仲裁节点可以部署在配置很低的机器上吗？](#Q1：KaiwuDB 仲裁节点可以部署在配置很低的机器上吗？)
- [Q2：KaiwuDB 启用双副本策略后，还能切换回三副本吗？](#Q2：KaiwuDB 启用双副本策略后，还能切换回三副本吗？)
- [Q3：KaiwuDB 双副本方案能容忍几个节点同时故障？](#Q3：KaiwuDB 双副本方案能容忍几个节点同时故障？)
- [Q4：KaiwuDB 双副本方案的 RPO 是多少？](#Q4：KaiwuDB 双副本方案的 RPO 是多少？)
相关推荐

一、 KaiwuDB 双副本仲裁节点设计思路

1、高可用不是"要不要"，而是"怎么选"

数据库宕机是每个团队都不愿面对的场景。系统卡死、应用报错、客服电话被打爆------做后端或者 DBA 的人对此都不陌生。衡量高可用有两个核心指标：

RPO（Recovery Point Objective）：能容忍丢失多少数据，RPO 为 0 意味着数据零丢失。
RTO（Recovery Time Objective）：恢复需要多长时间，RTO 10 秒意味着故障后 10 秒内必须恢复服务。

不同场景对这两个指标的要求差异很大：金融交易必须 RPO 为 0，物联网传感器采集场景则可以容忍几秒的数据丢失。这也意味着高可用方案的选择必须回到业务场景本身。

2、分布式共识协议的"多数派"代价

当前分布式数据库的主流高可用方案是多副本加分布式共识协议------数据在多个节点保留多份副本，通过 RAFT 或 Paxos 等协议实现自动选主和故障转移。RAFT 协议的核心是"多数派"（quorum）机制：一个决策要生效，必须获得超过半数的节点同意。三副本的多数派是两票，意味着三个节点里最多只能坏一个------另外两个节点仍然能达成共识。如果同时坏掉两个节点，剩余节点只有一票，无法形成多数派，集群就会停摆。

三副本的好处显而易见：容错能力强、数据可靠性高、读写负载均匀分布。但代价也不小------三倍的存储开销。如果时序数据量很大，三副本意味着三倍的磁盘成本。而且实际生产中的服务器很少是同一批采购的，新旧机器混用是常态，三台机器里总有一台配置明显偏低。如果用这台旧机器跑完整数据副本，可能成为性能瓶颈；闲置不用，资源又浪费了。

3、在成本与可靠性之间找平衡点

这就引出了一个问题：有没有办法在保留自动故障转移能力的前提下，适当降低存储成本？能不能少存一份数据，但通过其他方式弥补投票能力、让 RAFT 仍然能正常工作？如果直接把三副本去掉一个副本变成双副本，任何一个节点故障都会导致剩余节点无法形成多数派（1/2），RAFT 无法正常运转。所以简单去掉一个副本行不通。

KaiwuDB 的解决思路是在保留两个完整数据副本的基础上，引入一个不存储时序数据的"仲裁者"。这个角色只参与 RAFT 投票，不存储实际时序数据。这样一来，多数派还是两票------两个数据副本的票，或者一个数据副本加仲裁者的票。两台数据节点和一台仲裁节点，其中任意一个故障，集群仍然能达成共识。

这种方案在成本和可用性之间找到了一个折中点：存储开销从三倍降到两倍多一点（时序数据部分），同时保留了自动故障转移的能力。数据副本少了，写入的负载均衡能力会弱一些，极端情况下数据丢失的风险也比三副本略高。这不是一个"更好"的方案，而是一个在特定场景和约束下"更合适"方案。

二、KaiwuDB 双副本仲裁方案核心设计

在上一篇KaiwuDB 运维实战 02：多副本集群副本数量选型，副本越多性能越好吗？中，我们提到一个核心矛盾：中，我们提到一个核心矛盾：三副本虽然可靠，但存储成本是单节点的 3 倍，对于时序数据占比极高的物联网场景，这笔开销并不划算。 KaiwuDB V3.2.x 引入的双副本仲裁方案，本质上是用 2 个数据副本 + 1 个仲裁副本 替代标准三副本。仲裁节点只参与 Raft 共识投票，不存储时序业务数据，因此可以部署在配置较低或异构的机器上。

这里需要先明确三个核心概念：

概念	职责	能否成为 Leaseholder
数据副本（Data Replica）	存储实际时序业务数据，参与 Raft 选举	是
仲裁副本（Arbitration Replica）	不存储时序业务数据，参与 Raft 共识和选举	否
仲裁节点（Arbiter Node）	承载仲裁副本，存储关系数据和元数据，参与集群心跳	---

整体总共有如下几条关键约束：

双副本策略要求集群中至少有 2 个数据节点和 1 个仲裁节点。
每个数据分片的副本构成固定为 2 个数据副本 + 1 个仲裁副本，不允许通过 CONFIGURE ZONE USING num_replicas 修改副本数量。
双副本策略只能通过 ALTER RANGE ts CONFIGURE ZONE USING arbiter = true 或 ALTER DATABASE ... CONFIGURE ZONE USING arbiter = true 启用，不支持表级别设置，不支持对已有表从三副本切换为双副本。
启用双副本后，不支持切换回三副本模式。

三、KaiwuDB 双副本仲裁节点部署

部署前准备

1、节点规划与硬件要求

双副本集群的最小配置为 2 个数据节点 + 1 个仲裁节点 ，共 3 台机器。

仲裁节点的硬件可以显著低于数据节点，这是双副本方案降本的核心。但仲裁节点仍需存储关系数据和元数据，并参与集群心跳，因此不能完全无盘部署。

2、环境配置

三节点需要提前完成以下基础配置：

时钟同步：所有节点启用 NTP，确保节点间时间误差不超过 500 ms
SSH 免密登录：数据节点之间配置免密，便于批量运维
防火墙放行：开放 26257（数据库服务端口）、8080（Web 端口）、27257（BRPC 端口）

Bash 复制代码

# 示例：配置主机名解析
sudo hostnamectl set-hostname node1  # 各节点分别设置
sudo vi /etc/hosts
192.168.3.10 node1
192.168.3.11 node2
192.168.3.12 node3

集群初始化与仲裁节点加入

1、初始化数据节点

在任意一台数据节点上执行集群初始化：

Bash 复制代码

# 适用版本：KaiwuDB V3.2.x
# 在 node1 上执行
./kwbase init --insecure --host=192.168.3.10:26257

初始化完成后，启动第一个数据节点：

Bash 复制代码

./kwbase start \
  --insecure \
  --store=/var/lib/kaiwudb \
  --listen-addr=192.168.3.10:26257 \
  --advertise-addr=192.168.3.10:26257 \
  --brpc-addr=:27257 \
  --http-addr=192.168.3.10:8080 \
  --background

启动第二个数据节点并加入集群：

Bash 复制代码

# 在 node2 上执行
./kwbase start \
  --insecure \
  --store=/var/lib/kaiwudb \
  --listen-addr=192.168.3.11:26257 \
  --advertise-addr=192.168.3.11:26257 \
  --brpc-addr=:27257 \
  --http-addr=192.168.3.11:8080 \
  --join=192.168.3.10:26257 \
  --background

预期输出： 控制台显示节点启动成功，日志中无 ERROR 级别报错。

2、加入仲裁节点

仲裁节点的启动命令与普通数据节点几乎一致，仅需增加 --arbiter 参数：

Bash 复制代码

# 在 node3（仲裁节点）上执行
./kwbase start \
  --insecure \
  --store=/var/lib/kaiwudb \
  --arbiter \
  --listen-addr=192.168.3.12:26257 \
  --advertise-addr=192.168.3.12:26257 \
  --brpc-addr=:27257 \
  --http-addr=192.168.3.12:8080 \
  --join=192.168.3.10:26257 \
  --background

注意事项：

--arbiter 参数必须在启动时指定，无法对已有节点动态切换为仲裁节点
仲裁节点仍需指定 --store 目录，用于存储关系数据和元数据

3、验证节点状态

连接任意节点，查看集群成员状态：

SQL 复制代码

-- 使用 psql 或 kwbase sql 连接
SHOW NODES;

预期结果应显示 3 个节点，其中仲裁节点的 membership 字段显示为 arbiter，数据节点显示为 normal。

启用双副本策略

双副本策略不是默认开启的，需要在集群初始化后手动启用。启用时集群中不能存在任何时序表，否则命令将失败。

1、全局启用

对集群内全部时序数据启用双副本：

SQL 复制代码

-- 适用场景：新建集群，尚未创建时序表
ALTER RANGE ts CONFIGURE ZONE USING arbiter = true;

效果： 系统随后将时序数据分片自动分配为 2 个数据副本 + 1 个仲裁副本，并将 Leaseholder 迁移至数据节点。

注意： 初始化完成后副本补足和 Leaseholder 迁移需要一定时间，期间首次建表的响应时间会略长于标准三副本集群。

2、按数据库启用

如果只想对特定时序数据库启用双副本：

SQL 复制代码

-- 目标数据库中不能存在时序表
ALTER DATABASE <db_name> CONFIGURE ZONE USING arbiter = true;

验证是否生效：

SQL 复制代码

-- 查看时序分片的副本分布
SHOW RANGES FROM TABLE <ts_table>;

预期结果应显示每个分片包含 2 个数据副本和 1 个仲裁副本。

扩缩容操作

双副本集群支持通过扩缩容处理节点故障或调整集群规模。每个数据分片的副本构成标准始终为 2 数据副本 + 1 仲裁副本，允许暂时缺少一个数据副本或仲裁副本，但不允许数据副本数量超过 2 个，也不允许仲裁副本数量超过 1 个。

1、加入新数据节点

Bash 复制代码

# 新数据节点启动命令与普通节点一致
./kwbase start \
  --insecure \
  --store=/data_new \
  --listen-addr=<new_node_address>:26257 \
  --advertise-addr=<new_node_address>:26257 \
  --brpc-addr=:27257 \
  --http-addr=<new_node_address>:8080 \
  --join=<existing_node_address>:26257 \
  --background

新节点加入后，系统可能触发副本自动均衡，将部分副本迁移至新节点。

2、加入新仲裁节点

Bash 复制代码

# 新仲裁节点需增加 --arbiter 参数
./kwbase start \
  --insecure \
  --store=/data_new \
  --arbiter \
  --listen-addr=<new_node_address>:26257 \
  --advertise-addr=<new_node_address>:26257 \
  --brpc-addr=:27257 \
  --http-addr=<new_node_address>:8080 \
  --join=<existing_node_address>:26257 \
  --background

3、退役故障节点

加入新节点后，可执行退役操作移除故障节点，退役操作会将故障节点上的副本迁移至新节点，等待命令执行完成后，所有副本已在新节点上补全。也可以不立即执行退役，等待故障节点被系统判定为死亡后，系统会自动在其他节点上补足副本。

Bash 复制代码

# 退役指定节点，系统会将该节点上的副本迁移至其他节点
./kwbase node decommission <node_id> --insecure --host=<address>:26257

约束条件：

退役数据节点时，集群中必须至少有 3 个数据节点（即除目标节点外至少还有 2 个数据节点）
退役仲裁节点时，集群中必须至少有 2 个仲裁节点
如果没有加入同类型的新节点以替代故障节点，缩容操作将失败

故障演练：单节点故障

双副本方案通过 Raft 投票机制实现高可用，可容忍任意一个节点故障。

1、数据节点故障

场景： node1（数据节点）突然宕机。

预期行为：

剩余 1 个数据副本（node2）与仲裁副本（node3）组成 2/3 多数，达成 Raft 共识
由剩余数据节点继续对外提供读写服务
节点恢复后，自动重新加入集群并与 Leader 完成数据同步，读写服务不受影响

验证命令：

SQL 复制代码

-- 在 node2 上查询集群状态
SELECT * FROM kwdb_internal.kv_node_status;
-- 确认 node1 状态为 unavailable，但读写操作仍正常

2、仲裁节点故障

场景： node3（仲裁节点）突然宕机。

预期行为：

2 个数据副本自身即可达成 2/2 多数，集群读写服务不受影响
仲裁节点恢复后，自动重新加入集群，恢复投票能力

关键差异： 仲裁节点故障对业务零影响，因为数据副本之间已能形成多数派。

3、多节点故障风险提示

当任意两个节点同时故障时（包括两个数据节点同时故障，或一个数据节点与仲裁节点同时故障），集群无法达成多数共识，写入操作将失败。待任意一个节点恢复后，集群恢复服务。

监控与 RPO 配置

1、RPO 配置

双副本方案采用弱一致性保证：数据写入 Leader 副本后即视为成功，Follower 数据副本可能存在短暂落后。可通过 ts.arbiter.rpo_max_duration 控制数据同步周期。ts.arbiter.rpo_max_duration 用于控制双副本模式下数据节点间数据同步的时间周期，即最大允许丢失的数据时间范围。仅在启用双副本模式时生效。

SQL 复制代码

-- 设置最大允许丢失的数据时间范围为 60 秒
SET CLUSTER SETTING ts.arbiter.rpo_max_duration = '60s';

取值	说明
`-1`（默认）	不进行 RPO 控制，数据节点之间无需周期性数据同步
大于 `1s` 的时间值	系统按设定周期在数据节点之间同步数据，强制同步期间阻塞写入

注意： 开启 RPO 控制后，如果有数据节点故障，写入将持续阻塞，直至数据节点恢复或新数据节点加入且故障节点退役。

2、查看节点状态

执行以下命令查看集群节点状态，输出中 node_mode 列显示各节点角色：

SQL 复制代码

./kwbase node status --insecure --host=<address>:26257

-- 输出示例
id |      address      |   sql_address     |  build  |         started_at          |         updated_at          |   locality    | is_available | is_live | node_mode
-----+-------------------+-------------------+---------+-----------------------------+-----------------------------+---------------+--------------+---------+-----------
1 | node_a:26257      | node_a:26257      | V3.2.0  | 2026-03-02 09:24:56.827856  | 2026-03-02 09:25:01.343206  | region=NODE1  | true         | true    | normal
2 | node_b:26257      | node_b:26257      | V3.2.0  | 2026-03-02 09:24:58.012345  | 2026-03-02 09:25:02.234567  | region=NODE2  | true         | true    | normal
3 | node_c:26257      | node_c:26257      | V3.2.0  | 2026-03-02 09:25:00.543210  | 2026-03-02 09:25:03.654321  | region=NODE3  | true         | true    | arbiter

node_mode 字段取值说明：

3、关键监控指标

在 KaiwuDB 内置监控平台的 debug/chart 页面，关注以下指标：

常见问题 FAQ

Q1：KaiwuDB 仲裁节点可以部署在配置很低的机器上吗？

可以。仲裁节点不存储时序业务数据，仅参与 Raft 共识投票，因此可部署在配置较低或与数据节点存在硬件差异的机器上。但仲裁节点仍需存储关系数据和元数据，并参与集群心跳，不能完全无盘部署。

Q2：KaiwuDB 启用双副本策略后，还能切换回三副本吗？

不能。双副本策略启用后不支持切换回三副本模式，也不支持对已有表从三副本切换为双副本。建议在启用前充分评估业务场景对数据一致性和可用性的要求。

Q3：KaiwuDB 双副本方案能容忍几个节点同时故障？

可容忍任意一个节点故障。当任意两个节点同时故障时，集群无法达成多数共识，写入操作将失败。

Q4：KaiwuDB 双副本方案的 RPO 是多少？

默认不限制（-1）。可通过 ts.arbiter.rpo_max_duration 配置数据同步周期，控制最大数据丢失量。开启后若数据节点故障，写入将持续阻塞。

双副本仲裁方案是 KaiwuDB V3.2.x 在成本与可靠性之间给出的一个双赢答案：没有牺牲高可用能力------任意单点故障仍能自动切换------却将时序数据的存储成本显著压缩。对于时序数据体量庞大、但对极端场景下多节点同时故障容忍度较低的业务，这是一个值得很多企业认真评估的方案选项。

你在生产环境中使用过双副本仲裁方案吗？遇到过哪些坑？欢迎在评论区分享你的经验。

KaiwuDB 运维实战 03：双副本仲裁节点部署与高可用实践

文章目录

一、 KaiwuDB 双副本仲裁节点设计思路

1、 高可用不是"要不要"，而是"怎么选"

2、分布式共识协议的"多数派"代价

3、 在成本与可靠性之间找平衡点

二、KaiwuDB 双副本仲裁方案核心设计

三、KaiwuDB 双副本仲裁节点部署

部署前准备

1、节点规划与硬件要求

2、环境配置

集群初始化与仲裁节点加入

1、初始化数据节点

2、加入仲裁节点

3、验证节点状态

启用双副本策略

1、全局启用

2、按数据库启用

扩缩容操作

1、加入新数据节点

2、加入新仲裁节点

3、退役故障节点

故障演练：单节点故障

1、数据节点故障

2、仲裁节点故障

3、多节点故障风险提示

监控与 RPO 配置

1、RPO 配置

2、查看节点状态

3、关键监控指标

常见问题 FAQ

Q1：KaiwuDB 仲裁节点可以部署在配置很低的机器上吗？

Q2：KaiwuDB 启用双副本策略后，还能切换回三副本吗？

Q3：KaiwuDB 双副本方案能容忍几个节点同时故障？

Q4：KaiwuDB 双副本方案的 RPO 是多少？

相关推荐

1、高可用不是"要不要"，而是"怎么选"

3、在成本与可靠性之间找平衡点