作者：wangzongyu
原文链接：https://blog.csdn.net/wangzongyu/article/details/147168082
1.概述
KWDB作为面向AIoT场景的新一代分布式多模数据库，提供了丰富的功能。 支持同一实例同时建立时序库和关系库并融合处理多模数据。
默认情况下，KWDB多副本集群支持高可用，能够实现故障转移和数据强一致性。集群中的各节点通过定期的心跳机制来维护连接和状态，以便及时发现故障并采取相应措施。本文将详细测试KWDB多副本集群的高可用方案。
2. 数据准备
root@
kwdb1:~
/kwdb_install# kwbase sql --host=10.1.248.95:26257 --certs-dir=/etc/kaiwudb/certs/ --user=wangzy
#
#
Welcome to the
KWDB
SQL shell.
#
All statements must be terminated by a semicolon.
#
To exit,
type: \q.
#
Enter
password:
#
Server
version:
KaiwuDB
2.2
.0 (x86_64-linux-gnu, built
2025/
03/
31
07:
20:
47, go1
.16
.15, gcc
9.4
.0) (same version
as client)
#
Cluster
ID: 65071f3e-f4a4-
48e4-9a4e-953f772bf661
#
#
Enter \?
for a brief introduction.
#
wangzy@
10.1
.248
.95:
26257/defaultdb> show users;
username | options | member_of
-----------+------------+------------
admin |
CREATEROLE | {}
root |
CREATEROLE | {admin}
wangzy | | {admin}
(
3 rows)
Time:
14.638175ms
2.1. 创建时序数据库数据
wangzy@
10.1
.248
.95:
26257/defaultdb>
CREATE
TS
DATABASE ts_db
RETENTIONS 10d
PARTITION
INTERVAL 2d;
wangzy@
10.1
.248
.95:
26257/defaultdb>
SHOW
CREATE
DATABASE ts_db;
database_name | create_statement
----------------+------------------------------
ts_db |
CREATE
TS
DATABASE ts_db
| retentions 864000s
| partition interval 2d
(
1 row)
wangzy@
10.1
.248
.95:
26257/defaultdb> use ts_db;
创建t1时序表并写入数据：
use ts_db;
CREATE
TABLE ts_db.
t1(ts timestamp not
null,a int, b int)
tags(tag1 int not
null, tag2 int) primary
tags(tag1);
向表中写入数据，并查看表中的数据：
INSERT
INTO ts_db.
t1
VALUES(
now(),
11,
11,
33,
44);
INSERT
INTO ts_db.
t1
VALUES(
now(),
22,
22,
33,
44);
INSERT
INTO ts_db.
t1
VALUES(
now(),
11,
33,
33,
44);
INSERT
INTO ts_db.
t1
VALUES(
now(),
22,
44,
33,
44);
INSERT
INTO ts_db.
t1
VALUES(
now(),
33,
55,
44,
44);
INSERT
INTO ts_db.
t1
VALUES(
now(),
22,
44,
44,
44);
INSERT
INTO ts_db.
t1
VALUES(
now(),
33,
44,
55,
44);
INSERT
INTO ts_db.
t1
VALUES(
now(),
null,
null,
66,
66);
INSERT
INTO ts_db.
t1
VALUES(
now(),
null,
null,
66,
77);
SELECT *
FROM t1;
ts | a | b | tag1 | tag2
--------------------------------+------+------+------+-------
2025-
04-
14
02:
39:
40.34+
00:
00 |
NULL |
NULL |
66 |
66
2025-
04-
14
02:
39:
42.398+
00:
00 |
NULL |
NULL |
66 |
66
2025-
04-
14
02:
39:
40.336+
00:
00 |
33 |
44 |
55 |
44
2025-
04-
14
02:
39:
40.327+
00:
00 |
33 |
55 |
44 |
44
2025-
04-
14
02:
39:
40.332+
00:
00 |
22 |
44 |
44 |
44
2025-
04-
14
02:
39:
40.304+
00:
00 |
11 |
11 |
33 |
44
2025-
04-
14
02:
39:
40.314+
00:
00 |
22 |
22 |
33 |
44
2025-
04-
14
02:
39:
40.319+
00:
00 |
11 |
33 |
33 |
44
2025-
04-
14
02:
39:
40.323+
00:
00 |
22 |
44 |
33 |
44
(
9 rows)
2.2. 创建关系数据库数据
wangzy@
10.1
.248
.95:
26257/ts_db>
CREATE
DATABASE reldb1
WITH
ENCODING =
'UTF8';
wangzy@
10.1
.248
.95:
26257/ts_db> use reldb1;
创建accounts表：
CREATE TABLE reldb1.accounts(id INT8 DEFAULT unique_rowid() PRIMARY KEY, name STRING, balance DECIMAL, enabled BOOL);
写入数据：
INSERT INTO accounts VALUES (1, 'lily', 10000.5, true), (2, 'ruarc', 20000.75, true), (3, 'tullia', 30000, false), (4, 'arturo', 45000, false);
SELECT *
FROM accounts;
id | name | balance | enabled
-----+--------+----------+----------
1 | lily |
10000.5 |
true
2 | ruarc |
20000.75 |
true
3 | tullia |
30000 |
false
4 | arturo |
45000 |
false
(
4 rows)
3. KWDB数据备份
提前备份数据，防止后续的验证中造成数据丢失，生产环境中也要定期进行数据备份
KWDB支持通过数据导入、导出的方式进行数据库库级别和表级别的数据备份。KWDB支持一次性导出指定数据库中所有表的元数据、用户数据和权限信息。当然也可以导出指定的表，因为我的目的是对数据库进行下备份，防止后面测试过程中数据丢失。便于恢复，本次我就导出库的全部表数据。在生产环境也要定时对数据库进行备份。
■ 将时序数据库的用户数据和元数据导出到本地节点，当然也可以导出到指定的服务器：
wangzy@
10.1
.248
.95:
26257/reldb1>
EXPORT
INTO
CSV
"nodelocal://1/ts_db"
FROM
DATABASE ts_db;
result
-----------
succeed
(
1 row)
Time:
573.496633ms
- • nodelocal:///：将文件导出至本地节点。
- • node_id：节点 ID。当本地只有一个节点时，node_id 取值是 1。
- • dir：存放导出数据的文件夹名称。如果目标文件夹不存在，系统会在安装 KWDB 时定义的 KWDB 数据存放路径下创建相应的文件夹。默认情况下，KWDB 数据存放路径是
/var/lib/kaiwudb/extern/
导出的时序表位于public 模式下。每张表是一个单独的目录，用于存放该表的用户数据（.csv 文件）。导出的时序数据库数据组织形式如下所示：
root@
kwdb1:
/data/kaiwudb/extern# pwd
/data/kaiwudb/extern/ts_db
root@
kwdb1:
/data/kaiwudb/extern/ts_db# tree
.
├── meta.
sql
└── public
└── t1
└── n2
.0.
csv
2 directories,
2 files
■ 将关系数据库的用户数据和元数据导出到本地节点，当然也可以导出到指定的服务器：
wangzy@
10.1
.248
.95:
26257/reldb1>
EXPORT
INTO
CSV
"nodelocal://1/rdb"
FROM
DATABASE reldb1;
filename | rows | node_id | file_num
-------------------------------+------+---------+-----------
TABLE reldb1.
public.
accounts |
4 |
2 |
1
meta.
sql |
1 |
1 |
1
(
2 rows)
Time:
588.889273ms
导出的关系表按其所在模式进行组织。每张表是一个单独的目录，用于存放该表的元数据信息（meta.sql）和用户数据（.csv 文件）。导出的关系库数据组织形式如下所示：
root@
kwdb1:
/data/kaiwudb/extern/rdb# pwd
/data/kaiwudb/extern/rdb
root@
kwdb1:
/data/kaiwudb/extern/rdb# tree
.
├── meta.
sql
└── public
└── accounts
├── meta.
sql
└── n2
.0.
csv
2 directories,
3 files
4. KWDB高可用方案测试
KWDB多副本集群默认采用3副本机制。为了确保系统在节点发生故障后仍能够提供服务，集群通过多数投票机制保证数据一致性和可用性，因此至少需要2个副本保持可用状态。
前面已经搭建了一个3节点的集群，接下来以3节点集群为例，说明KWDB多副本集群如何实现高可用性。
● 正常运行的情况：KWDB集群启动后，副本和leaseholder均匀分布在所有节点上，确保数据的高可用性和平衡性
看一下目前集群的状态情况：
4.1. 单节点状态异常情况
● 单节点异常情况（非故障）：如果单个节点因网络断开、延迟、操作系统故障、磁盘故障等原因导致节点状态变为异常（is_available 和is_live均为 false），系统会开始迁移该节点的leaseholder，迁移期间数据查询和 DML 操作可能受影响，DDL 操作可能会报错，生命周期会顺延至下一执行周期执行。待节点恢复为可用状态后恢复正常。
将NODE3（kwdb3）节点的kaiwudb服务关停，模拟节点出现异常：
root@kwdb3:~# systemctl stop kaiwudb
查看集群状态NODE3（kwdb3）的is_available变为false，is_live状态变为false：
验证服务写入和查询无影响：
wangzy@
10.1
.248
.95:
26257/reldb1>
INSERT
INTO accounts
VALUES (
5,
'wangzy',
90000.9,
true);
INSERT
1
Time:
2.979627ms
wangzy@
10.1
.248
.95:
26257/reldb1>
SELECT *
FROM accounts;
id | name | balance | enabled
-----+--------+----------+----------
1 | lily |
10000.5 |
true
2 | ruarc |
20000.75 |
true
3 | tullia |
30000 |
false
4 | arturo |
45000 |
false
5 | wangzy |
90000.9 |
true
(
5 rows)
Time:
2.782496ms
4.2. 单节点故障情况
● 单节点故障情况：节点离线时间达到设定值后，系统会将该节点标记为不可用。如果剩余节点数量仍大于副本数，系统自动补足缺失的副本，确保数据的高可用性、副本补足期间，数据查询不受影响，DML操作不受影响，DDL操作可能会报错，副本补足后，DDL操作恢复正常。
先将NODE3（kwdb3）节点的kaiwudb服务启动，恢复集群状态为正常：
接下来模拟将NODE3（kwdb3）节点直接关机：
root@kwdb3:~# shutdown -h now
查看集群状态，由于系统检测到故障节点后会开始迁移该节点的leaseholder，迁移期间数据查询和 DML 操作可能受影响，所以会卡顿一下。
但是查询依然没有受到影响：
wangzy@
10.1
.248
.95:
26257/reldb1>
INSERT
INTO accounts
VALUES (
6,
'wangzongyu',
8800,
true);
wangzy@
10.1
.248
.95:
26257/reldb1>
SELECT *
FROM accounts;
id | name | balance | enabled
-----+------------+----------+----------
1 | lily |
10000.5 |
true
2 | ruarc |
20000.75 |
true
3 | tullia |
30000 |
false
4 | arturo |
45000 |
false
5 | wangzy |
90000.9 |
true
6 | wangzongyu |
8800 |
true
(
6 rows)
Time:
3.737195ms
● 节点恢复情况：不可用节点恢复后，系统会将副本和leaseholder 回迁到该节点，迁移期间数据查询和DML操作可能受影响，DDL操作可能会报错，生命周期会顺延至下一执行周期执行。待节点恢复为可用状态后恢复正常。
集群恢复到正常状态：
4.3. 多节点故障情况
● 多节点故障情况：如果两个或更多节点出现故障，由于剩余节点数小于或等于副本数，系统无法补足缺失的副本，可能导致部分数据无法访问，甚至出现集群无法使用的情况。
root@
kwdb2:~# shutdown -h now
root@
kwdb3:~# shutdown -h now
root@
kwdb1:~
/kwdb_install# ./deploy.
sh cluster --status
ERROR: cannot dial server.
Is the server running?
If the server is running, check --host client-side and --advertise server-side.
read tcp
127.0
.0
.1:
1730->
127.0
.0
.1:
26257: i/o timeout
Failed running
"node status"
当两个节点故障后，KWDB集群将无法再使用。
5. 总结
集群节点多次发生故障后重新加入，可能会导致数据写入缓慢。而且集群节点故障或故障节点恢复后的 leaseholder 迁移可能导致读写短暂不可用或卡顿。
故障节点标记：
默认情况下，如果一个节点在集群中离线时间超过30分钟，系统会将其标记为不可用，并将该节点上的数据副本重新分配到其他节点，以确保数据的可用性和一致性。（比如5个节点至少2副本的情况，当一台节点故障，这个节点上的副本会重新分配到其他节点）
用户也可以通过以下SQL命令设置节点死亡时间：
SET CLUSTER SETTING server.time_until_store_dead = <value>; // 设置时间建议不小于75s
延长节点死亡判定时间，可以减少节点故障对集群性能的长时间影响，但可能会影响集群的高可用性功能和DDL相关操作。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/70027415/viewspace-3090022/ ，如需转载，请注明出处，否则将追究法律责任。
最新文章
- 企业级异构数据库迁移的数据库选型实践：KaiwuDB 社区版 KWDB 数据迁移 Skill 解析
- 企业级边缘场景数据库高可用选型：KaiwuDB DRBD + Pacemaker 方案架构与运维要点
- InfluxDB ®版退市后的企业级迁移方案：KaiwuDB 迁移路径与信创考量
- KWDB MVP 招募令 | 寻找 KaiwuDB 开源社区的中坚力量！
- 征文大赛 |「KWDB 创作者计划」—— KaiwuDB 开源两周年特别季，来了！
- 2026数博会｜KaiwuDB 获央视关注，多模数据库的企业级选型价值分析
- 两年生长，开源同行 | KWDB 开源两周年
- 企业级时序数据库降本之道：KaiwuDB 双副本仲裁架构的选型与落地
- 企业级 AIoT 平台的数据库架构演进：KaiwuDB V3.2.2 高可用与数据安全实践
- 企业级时序数据库迁移实践：从 InfluxDB 到 KaiwuDB 的架构选型与落地路径
