从 0 到 1 部署 KaiwuDB 双副本仲裁集群：踩坑记录与运维笔记

双副本不是简单的"少存一份"。如果没有仲裁节点，两副本在 Raft 下是灾难：挂一个就剩 1/2，凑不成多数派。KaiwuDB 的解法是引入仲裁副本——不存时序数据，只参与投票，这样 2 数据 + 1 仲裁在任意单点故障时仍能形成多数派。

KaiwuDB 双副本+仲裁节点，从 0 到 1 部署实录

环境：3 台 CentOS，node1/node2 为数据节点，node3 为仲裁节点。

node1 初始化：

./kwbase init --insecure --host=192.168.3.10:26257

node1/node2 启动（node2 加 --join），node3 启动时加 --arbiter 并 --join。

启用双副本：

ALTER RANGE ts CONFIGURE ZONE USING arbiter = true;

四、踩坑记录

1. 启用时机： 集群里必须没有时序表，否则 ALTER RANGE 直接失败。

2. 角色切换： --arbiter 只能在启动时加，已经跑起来的节点不能动态切角色。

3. 存储目录： 仲裁节点虽然低配，但 --store 目录不能省，元数据和关系数据还得存。

4. 退役顺序： 退役节点前先加新节点，否则 decommission 会因为副本不足而卡住。

五、故障演练结果

• 拔网线模拟 node1 宕机：node2 + node3 继续服务，读写无感知。

• 拔网线模拟 node3 宕机：node1 + node2 继续服务，业务零影响。

• 同时拔 node1+node3：写入失败，恢复 node1 后集群自动恢复。

六、写在最后

双副本仲裁方案适合时序数据体量大、能接受双点故障底线的业务。可以在测试环境压测 RPO 开启后的写入延迟表现，再决定是否上生产。更详细的内容可前往 KaiwuDB官方文档，如果你也在做类似的选型，欢迎交流踩坑经验。