KaiwuDB安装避坑指南：从环境校验到集群初始化-平芜编程栈

1. 为什么说“瞎装”数据库是多数人踩坑的起点？

KaiwuDB 这个名字在工业物联网、能源监控、智能制造等垂直领域里，最近两年出现频率越来越高。它不是另一个 MySQL 或 PostgreSQL 的平替，而是一个从底层就为时序数据+空间数据+关系数据三模融合设计的国产数据库。我第一次接触 KaiwuDB 是在给一家风电场做边缘数据网关升级时，客户原有 MySQL + InfluxDB 双写架构在接入 200+ 风电机组后，写入延迟飙升到 8 秒以上，查询一个 7 天的功率曲线要等半分钟——这不是配置问题，是模型错配。KaiwuDB 的核心价值，恰恰在于它用一套存储引擎同时承载设备点位（关系）、传感器采样流（时序）、风机地理坐标与拓扑关系（空间），省掉 ETL 拆洗合的中间环节。但问题来了：很多人一上来就照着官网 Quick Start 执行curl -sSL https://get.kaiwudb.com | sh，结果卡在「服务启动失败」或「节点注册超时」，反复重装三次后放弃，转头又去折腾 Docker Compose 模板，最后发现连最基础的CREATE DATABASE都报错。这不是你手生，是没搞清 KaiwuDB 的安装逻辑本质——它不像传统数据库那样「装完即用」，而是一套「先建共识、再启服务、后挂存储」的分布式系统初始化流程。它的安装过程，本质上是在本地模拟一个最小可用集群的诞生仪式。你跳过节点发现机制、跳过元数据目录初始化、跳过 WAL 日志路径校验，就像没打地基就砌墙，表面看着立住了，风一吹就倒。尤其当你的机器上还跑着 MySQL、PostgreSQL 或者 Docker Desktop 自带的 Hyper-V 虚拟化服务时，端口冲突、内存抢占、文件锁竞争会直接让kaiwudb-server进程在启动第 3 秒就静默退出，日志里只有一行failed to bind port 5432，根本看不出是被另一个进程占了。所以「别再瞎装」，不是说安装有多难，而是必须理解：KaiwuDB 的安装命令不是在「安装软件」，而是在「宣告一个集群的出生」。你执行的每一行命令，都在向本地文件系统、网络栈和进程管理器发出明确的契约声明。下面我会把整个过程拆成可验证、可回溯、可调试的四个阶段，不讲概念，只讲你敲下回车后，系统到底在做什么、为什么这么做、哪里容易断、怎么一眼看出断在哪。

2. 安装前的硬性检查清单：绕不开的 7 个「物理层」确认项

KaiwuDB 对运行环境的要求，不是写在文档末尾的「建议配置」，而是刻在启动校验逻辑里的硬门槛。我见过太多人因为跳过这一步，在凌晨两点对着systemctl status kaiwudb的红色报错发呆。下面这 7 项，必须逐条手动验证，不能靠感觉，不能信free -h的模糊输出，更不能依赖 Docker 容器的虚拟化隔离——KaiwuDB 默认不跑在容器里，它要直接调度宿主机资源。

2.1 内存与交换分区的真实水位线

KaiwuDB 启动时会强制检查可用内存是否 ≥ 4GB，但它检查的不是free -h显示的available值，而是/proc/meminfo中的MemAvailable字段减去当前所有进程 RSS 总和后的净剩余。实测发现，当系统运行着 Chrome（开 15 个标签页）、VS Code（加载 3 个 Python 项目）、Docker Desktop（含 WSL2 后端）时，free -h显示还有 5.2G，但 KaiwuDB 启动脚本读取MemAvailable后计算出净剩余仅 2.8G，直接拒绝启动并报错insufficient memory: need 4096MB, got 2816MB。解决方法不是关掉浏览器，而是用echo $(awk '/MemAvailable/{print $2}' /proc/meminfo) / 1024 | bc算出真实 MB 数，再用ps aux --sort=-%mem | head -n 10查看内存大户。重点盯住WSL2进程（Windows 用户）和com.docker.backend（Mac 用户），它们常驻后台却吃掉 1.5G+ 内存。我的经验是：安装前先执行sudo swapoff -a && sudo swapon -a强制刷新交换分区状态，再运行 KaiwuDB 安装脚本，成功率提升 60%。

2.2 文件系统与磁盘 I/O 能力的隐性约束

KaiwuDB 默认将 WAL（预写日志）和数据目录放在/var/lib/kaiwudb，但它对底层文件系统的容忍度极低。在 ext4 分区上，如果挂载参数包含noatime,nodiratime,barrier=1，一切正常；但若用了 XFS 并启用了inode64选项，kaiwudb-init初始化元数据时会在第 17 步（创建 system_catalog 表空间）卡死，strace -p $(pgrep kaiwudb-init)显示进程在反复调用openat(AT_FDCWD, "/var/lib/kaiwudb/data/system_catalog", O_RDONLY|O_CLOEXEC)后陷入futex等待。根本原因是 KaiwuDB 的元数据锁管理器依赖 ext4 的i_versioninode 特性，XFS 的inode64会破坏该特性的时间戳一致性。解决方案只有两个：要么改用 ext4 格式化目标磁盘（sudo mkfs.ext4 /dev/sdb1），要么在 XFS 上显式关闭inode64（sudo mkfs.xfs -n ftype=1 -d agcount=16 /dev/sdb1）。别信网上说的「XFS 更适合数据库」，KaiwuDB 的源码里硬编码了对 ext4i_version的校验逻辑。

2.3 网络端口与防火墙的「静默拦截」

KaiwuDB 集群通信使用 3 个固定端口：5432（SQL 接入）、7001（Raft 协议）、7002（Gossip 发现）。但问题在于，Windows Defender 防火墙和 macOS 的pfctl在默认策略下，会对未签名的kaiwudb-server二进制文件执行「连接限制」——它不弹窗提示，也不记录日志，只是让telnet localhost 7001永远显示Connection refused。验证方法很简单：在安装前，先用nc -zv localhost 7001测试端口连通性，如果返回Connection refused，立刻执行sudo lsof -i :7001查看是否有其他进程占用；若无占用，再运行sudo ss -tuln | grep ':7001'，如果输出为空，说明防火墙已拦截。Windows 用户需打开「高级安全 Windows 防火墙」→「入站规则」→ 新建规则 → 程序 → 选择kaiwudb-server的绝对路径（如C:\Program Files\KaiwuDB\bin\kaiwudb-server.exe）→ 允许连接。Mac 用户则需执行sudo pfctl -f /etc/pf.conf临时关闭，或在/etc/pf.conf末尾添加pass in proto tcp from any to any port 7001后重载。

2.4 SELinux 与 AppArmor 的策略冲突

这是 Linux 发行版用户最容易忽略的雷区。CentOS 7/8、Rocky Linux 默认启用 SELinux，其targeted策略会阻止 KaiwuDB 访问/var/lib/kaiwudb目录下的wal/子目录，因为该目录的 SELinux 上下文类型被标记为default_t，而 KaiwuDB 的执行域要求kaiwudb_var_lib_t。现象是：kaiwudb-server进程能启动，但 10 秒后自动退出，journalctl -u kaiwudb里只有一行avc: denied { write } for pid=1234 comm="kaiwudb-server" name="wal" dev="sda2" ino=56789 scontext=system_u:system_r:kaiwudb_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir。解决方法不是直接setenforce 0（这等于卸掉盔甲），而是用sudo semanage fcontext -a -t kaiwudb_var_lib_t "/var/lib/kaiwudb(/.*)?"定义上下文，再用sudo restorecon -Rv /var/lib/kaiwudb重置。Ubuntu 用户同理，sudo aa-status查看 AppArmor 是否启用，若aa-unconfined | grep kaiwudb有输出，说明被拦截，需编辑/etc/apparmor.d/usr.bin.kaiwudb-server添加owner /var/lib/kaiwudb/** rwk,规则。

2.5 时间同步精度的毫秒级要求

KaiwuDB 的 Raft 选举超时时间设为 1500ms，这意味着所有节点的系统时钟偏差必须控制在 ±500ms 内，否则会出现「脑裂」：两个节点都认为自己是 Leader，各自接受写请求，导致数据不一致。普通 NTP 服务（如systemd-timesyncd）的同步精度通常在 ±50ms，够用；但如果你的机器在 VMware Workstation 里运行，且启用了「时间同步到主机」选项，VMware Tools 会每 60 秒强制校正一次虚拟机时钟，造成瞬时跳变（如从 10:00:00.123 跳到 10:00:00.001），Raft 模块检测到时钟倒流会立即终止选举。验证方法：timedatectl status查看System clock synchronized是否为yes，再运行ntpq -p看offset列是否始终在 ±10ms 内波动。生产环境必须用chrony替代systemd-timesyncd，并配置makestep 1.0 -1参数允许在启动时大步长校正。

2.6 CPU 架构与指令集的硬性匹配

KaiwuDB 官方只提供 x86_64 和 aarch64 两种架构的二进制包，但它对 CPU 指令集有隐藏要求：必须支持AVX2指令集。我在一台老款 Intel Xeon E5-2620 v2（仅支持 AVX）的服务器上安装时，kaiwudb-server启动后立即崩溃，dmesg | tail显示traps: kaiwudb-server[1234] trap invalid opcode ip:7f8b9c7a1234 sp:7fffe1234567 error:0 in libkaiwudb.so[7f8b9c7a0000+100000]。这是因为 KaiwuDB 的向量计算模块（用于时空索引加速）编译时启用了-mavx2优化。验证方法：grep avx2 /proc/cpuinfo，若无输出，则不可用。ARM 服务器同理，需grep asimd /proc/cpuinfo确认支持 Advanced SIMD 指令。

2.7 用户权限与文件所有权的精确绑定

KaiwuDB 不允许以 root 用户直接运行服务进程，但安装脚本又必须用 root 权限创建目录和软链接。这就形成一个经典矛盾：安装时用sudo ./install.sh，但启动时必须切换到普通用户。很多教程教大家chown -R kaiwu:kaiwu /var/lib/kaiwudb，这看似合理，但 KaiwuDB 的日志模块在初始化时会尝试创建/var/log/kaiwudb/目录，而该目录的属主必须是kaiwu用户，属组必须是kaiwu组，且权限必须是755。如果kaiwu用户的 UID 是 1001，但/var/log/kaiwudb的属主 UID 是 1002（比如之前用另一个用户创建过），kaiwudb-server会因无法写入日志而退出。正确做法是：先用sudo useradd -r -s /bin/false kaiwu创建系统用户，再用sudo mkdir -p /var/log/kaiwudb && sudo chown kaiwu:kaiwu /var/log/kaiwudb && sudo chmod 755 /var/log/kaiwudb三步原子化操作，最后才运行安装脚本。

提示：这 7 项检查必须在安装命令执行前完成，任何一项不满足，后续所有操作都是在浪费时间。我建议把它们做成一个 shell 脚本precheck.sh，每次安装前先运行bash precheck.sh，输出✅ All checks passed才继续。

3. 从零构建单节点集群：安装命令背后的 5 层执行逻辑

KaiwuDB 的安装命令curl -sSL https://get.kaiwudb.com | sh看似一行，实则触发了 5 层嵌套的自动化流程。理解每一层在做什么，比记住命令本身重要十倍。下面我以 Ubuntu 22.04 为例，逐层拆解这个命令背后的真实动作。

3.1 第一层：下载与校验（3 秒内完成）

curl -sSL https://get.kaiwudb.com获取的是一个 2KB 的 shell 脚本，不是二进制包。该脚本第一件事是检查当前系统架构：uname -m输出x86_64时，它会拼接下载地址https://download.kaiwudb.com/kaiwudb-2.3.0-ubuntu22.04-x86_64.tar.gz；输出aarch64时则换为 ARM 地址。接着它用sha256sum对比官网公布的 checksum 值（硬编码在脚本里），若不匹配，脚本立即退出并打印❌ Download corrupted, expected SHA256: xxx, got yyy。这一步的意义在于：防止中间人攻击篡改安装包，也避免 CDN 缓存脏数据。我曾遇到某次阿里云 CDN 节点故障，返回了 404 页面的 HTML 内容，脚本校验失败后直接终止，保住了我的系统不被污染。

3.2 第二层：解压与布局（12 秒，关键路径）

脚本下载完 tar.gz 包后，执行tar -xzf kaiwudb-2.3.0-ubuntu22.04-x86_64.tar.gz -C /tmp/kaiwudb-install解压到临时目录。注意，它不直接解压到/opt/kaiwudb，而是先在/tmp中完成所有文件校验。解压后，脚本遍历bin/、lib/、share/三个目录，对每个文件执行file命令检查 ELF 格式是否正确（排除文本文件误传），再用ldd bin/kaiwudb-server | grep "not found"检查动态库依赖是否完整。若发现libssl.so.1.1缺失（Ubuntu 22.04 默认装libssl.so.3），脚本会自动apt install libssl1.1并继续。这一步完成后，脚本才执行sudo mv /tmp/kaiwudb-install /opt/kaiwudb，将整个目录移到最终位置。所以，如果你看到/opt/kaiwudb下没有bin/目录，一定是第二层解压失败，要去/tmp/kaiwudb-install查看残留文件。

3.3 第三层：符号链接与环境注入（5 秒，决定启动成败）

移动完文件，脚本开始创建全局可访问的符号链接：

sudo ln -sf /opt/kaiwudb/bin/kaiwudb-server /usr/local/bin/kaiwudb-server sudo ln -sf /opt/kaiwudb/bin/kaiwudb-cli /usr/local/bin/kaiwudb-cli

但这只是表象。真正关键的是它向/etc/profile.d/kaiwudb.sh写入三行环境变量：

export KAIWUDB_HOME=/opt/kaiwudb export PATH=$KAIWUDB_HOME/bin:$PATH export LD_LIBRARY_PATH=$KAIWUDB_HOME/lib:$LD_LIBRARY_PATH

其中LD_LIBRARY_PATH是生死线。KaiwuDB 的核心存储引擎libkaiwudb.so依赖librocksdb.so.7.10，而 RocksDB 的.so文件就放在/opt/kaiwudb/lib/下。如果不设置LD_LIBRARY_PATH，kaiwudb-server启动时会报error while loading shared libraries: librocksdb.so.7.10: cannot open shared object file。我试过用patchelf --set-rpath /opt/kaiwudb/lib /opt/kaiwudb/bin/kaiwudb-server修改 rpath，但 KaiwuDB 的某些插件模块（如空间索引）仍会动态加载失败，所以官方坚持用LD_LIBRARY_PATH方案。

3.4 第四层：系统服务注册（8 秒，Linux 专属）

在 systemd 系统上，脚本会生成/etc/systemd/system/kaiwudb.service文件，内容不是简单的[Service] ExecStart=...，而是包含 4 个关键防护：

MemoryLimit=4G：硬性限制内存上限，防 OOM Killer 杀进程
RestartSec=10：崩溃后 10 秒重启，避免快速失败循环
ProtectSystem=strict：挂载/usr,/boot,/etc为只读，防配置被意外修改
NoNewPrivileges=true：禁止进程获取新权限，防提权漏洞然后执行sudo systemctl daemon-reload && sudo systemctl enable kaiwudb。这里有个陷阱：enable只是创建软链接/etc/systemd/system/multi-user.target.wants/kaiwudb.service，并不启动服务。很多人以为enable就等于运行，结果systemctl status kaiwudb显示inactive (dead)，其实是没执行sudo systemctl start kaiwudb。

3.5 第五层：首次初始化（23 秒，真正的「集群诞生」）

当sudo systemctl start kaiwudb执行时，kaiwudb-server进程启动，它做的第一件事不是监听端口，而是执行kaiwudb-init初始化。这个初始化分 5 步：

检查元数据目录：若/var/lib/kaiwudb/cluster_meta不存在，则创建空目录
生成集群 ID：用hostname+MAC 地址+当前时间戳的 SHA256 哈希生成唯一cluster_id

写入初始配置：在/var/lib/kaiwudb/cluster_meta/config.json中写入：

{ "cluster_id": "a1b2c3d4...", "nodes": [{"id": "node-1", "addr": "127.0.0.1:7001", "role": "leader"}], "version": "2.3.0" }

初始化 WAL 日志：在/var/lib/kaiwudb/wal/下创建00000000000000000001.log文件，并写入 Raft 的初始日志条目（term=1, index=1, type=EntryConfChange）
启动 Raft 实例：加载config.json，将本节点注册为leader，开始监听7001端口等待其他节点加入

这 5 步全部成功，kaiwudb-server才会打印✅ KaiwuDB cluster initialized, leader node-1 ready并开始监听5432端口。如果卡在第 4 步，ls -l /var/lib/kaiwudb/wal/会显示00000000000000000001.log文件大小为 0，说明磁盘满或权限不足。

注意：这 5 层逻辑是串行的，上一层失败，下一层绝不会执行。所以当你看到安装脚本卡住时，不要盲目重试，先用ps aux | grep kaiwudb看进程是否存在，再用journalctl -u kaiwudb -n 50 -f实时跟踪日志，90% 的问题都能定位到具体哪一层。

4. 验证安装成功的 4 个黄金指标与 1 个必做操作

安装命令执行完毕，systemctl status kaiwudb显示active (running)，这只是万里长征第一步。真正的「安装成功」，必须通过以下 4 个可量化、可验证的黄金指标来确认。少一个，都算没装好。

4.1 指标一：端口监听状态的三重验证

不能只信netstat -tuln | grep 5432，必须交叉验证：

TCP 层：sudo ss -tuln | grep ':5432'应输出LISTEN 0 128 *:5432 *:* users:(("kaiwudb-server",pid=1234,fd=12))
进程层：sudo lsof -i :5432应显示kaiwudb-s 1234 kaiwu 12u IPv6 1234567 0t0 TCP *:postgresql (LISTEN)
应用层：echo "SELECT version();" | kaiwudb-cli -h 127.0.0.1 -p 5432 -U kaiwu应返回KaiwuDB 2.3.0 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit

为什么强调三重？因为ss只看内核 socket 状态，lsof看进程 fd 绑定，kaiwudb-cli才真正测试 SQL 协议栈是否就绪。我遇到过ss显示监听，但kaiwudb-cli连不上，strace kaiwudb-cli发现它卡在connect()系统调用，最终查出是iptables的OUTPUT链规则误拦了本地回环流量。

4.2 指标二：集群健康状态的 JSON 解析

KaiwuDB 提供 HTTP 健康检查端点http://127.0.0.1:7002/health，返回 JSON：

{ "status": "UP", "components": { "raft": {"status": "UP", "leader": "node-1"}, "storage": {"status": "UP", "used_ratio": "12.3%"}, "network": {"status": "UP", "latency_ms": 0.8} } }

关键看components.raft.status和components.raft.leader。如果leader字段为空或为null，说明 Raft 集群未形成，节点处于follower状态但找不到 leader，此时kaiwudb-cli可能连得上，但所有写操作都会报ERROR: not the leader。验证方法：curl -s http://127.0.0.1:7002/health | jq -r '.components.raft.leader'，输出必须是node-1（单节点时固定值）。

4.3 指标三：元数据目录的文件结构完整性

/var/lib/kaiwudb/是 KaiwuDB 的「心脏」，其子目录结构必须严格符合：

/var/lib/kaiwudb/ ├── cluster_meta/ # 集群元数据，含 config.json 和 raft_state.bin ├── data/ # 用户数据，含 database/ 和 tablespace/ ├── wal/ # WAL 日志，至少有一个 .log 文件且 size > 0 ├── log/ # 日志文件，kaiwudb-server.log 最后一行应为 "server started" └── tmp/ # 临时文件，可为空

用find /var/lib/kaiwudb -type d | wc -l应输出6（5 个目录 + 根目录），find /var/lib/kaiwudb -type f | wc -l应 ≥3（config.json,raft_state.bin,00000000000000000001.log）。如果wal/下没有.log文件，或cluster_meta/下没有raft_state.bin，说明初始化失败，必须删掉整个/var/lib/kaiwudb重来。

4.4 指标四：SQL 连接池的实时活跃数

KaiwuDB 的kaiwudb-cli自带连接池监控，执行：

kaiwudb-cli -h 127.0.0.1 -p 5432 -U kaiwu -c "SELECT * FROM pg_stat_activity WHERE state = 'active';"

正常应返回 1 行（当前 cli 连接自身），backend_start时间戳应为当前时间。如果返回空，说明连接池未建立；如果返回多行且state为idle in transaction，说明有未提交事务阻塞了连接。这是集群扩容前必须清理的状态，否则新节点加入时会因事务锁等待超时而失败。

4.5 必做操作：创建首个业务数据库并验证时空索引

安装成功的最后一道关卡，是亲手创建一个带时空特性的数据库，证明核心能力就绪：

-- 1. 创建数据库 CREATE DATABASE iot_demo; -- 2. 连接到新库 \c iot_demo -- 3. 创建带时间戳和坐标的设备表 CREATE TABLE wind_turbine ( id SERIAL PRIMARY KEY, name VARCHAR(50), location GEOGRAPHY(POINT,4326), -- 空间类型 ts TIMESTAMP WITH TIME ZONE, -- 时序主键 power_kW FLOAT ) PARTITION BY RANGE (ts); -- 按时间分区 -- 4. 插入一条测试数据 INSERT INTO wind_turbine (name, location, ts, power_kW) VALUES ('WT-001', ST_Point(116.39747, 39.90923), NOW(), 1250.5); -- 5. 查询验证空间索引生效 EXPLAIN ANALYZE SELECT * FROM wind_turbine WHERE ST_DWithin(location, ST_Point(116.39747, 39.90923), 1000);

EXPLAIN ANALYZE输出中必须出现Index Scan using <index_name> on wind_turbine，且Execution Time< 5ms。如果出现Seq Scan，说明空间索引未创建成功，要检查postgis扩展是否启用（KaiwuDB 内置，无需额外安装）。

实操心得：这 4 个指标和 1 个操作，我称之为「安装验收四象限」。每次给客户部署，我都用一个 Bash 脚本自动执行这 5 步，输出 ✅ 或 ❌，10 分钟内给出确定性结论。比盯着systemctl status看 1 小时有效得多。

5. 集群扩容的实操路径：从单节点到三节点的 7 个关键决策点

单节点 KaiwuDB 只是玩具，真正的价值在集群模式。但扩容不是简单复制粘贴install.sh，而是一系列需要人工判断的决策链。下面我以「将单节点扩展为 3 节点高可用集群」为例，还原真实扩容场景中的 7 个关键决策点，每个都附带我的血泪教训。

5.1 决策点一：节点角色分配——Leader/Follower/Voter 的取舍

KaiwuDB 集群中，节点有三种角色：leader（处理读写）、follower（只同步日志）、voter（参与 Raft 投票但不存数据）。3 节点集群的标准配置是1 leader + 2 follower，但如果你的第三台机器内存只有 2GB，就不能设为follower（它也要加载全量 WAL），而应设为voter。voter节点不存储用户数据，只保存 Raft 日志的元信息，内存占用 < 100MB。决策依据：用free -h看目标机器available值，≥ 3.5G 选follower，< 3.5G 选voter。我曾在一台 2GB 内存的树莓派上强行设follower，结果kaiwudb-server启动后 30 秒就被 OOM Killer 杀掉。

5.2 决策点二：网络发现方式——Gossip vs 静态配置的适用场景

KaiwuDB 支持两种节点发现方式：gossip（自动广播）和static（手动指定 IP）。gossip适合局域网，但要求所有节点能互相 ping 通且7002端口开放；static适合跨网段或防火墙严格的环境。决策依据：在新增节点上执行nc -zv 192.168.1.100 7002（原节点 IP），若通则用gossip，不通则用static。gossip配置只需在新节点的/opt/kaiwudb/conf/kaiwudb.conf中设discovery.mode=gossip；static则要写discovery.mode=static和discovery.static_nodes=["192.168.1.100:7001","192.168.1.101:7001"]。注意：static模式下，所有节点的static_nodes列表必须完全一致，否则形成多个孤岛集群。

5.3 决策点三：数据目录路径的一致性——绝对路径还是相对路径？

新节点的数据目录路径，必须与原节点完全相同。比如原节点用/data/kaiwudb，新节点就不能用/var/lib/kaiwudb。因为 KaiwuDB 的 Raft 日志中记录的是绝对路径的 WAL 文件名，路径不一致会导致新节点无法解析旧日志。决策依据：在原节点执行kaiwudb-cli -c "SHOW data_directory;"，输出就是必须复用的路径。我吃过亏：原节点路径是/data/kaiwudb，新节点图省事用了默认/var/lib/kaiwudb，结果kaiwudb-server启动后疯狂刷日志failed to load wal segment: /var/lib/kaiwudb/wal/00000000000000000001.log not found，其实文件在/data/kaiwudb/wal/下。

5.4 决策点四：时钟同步的强制校准——NTP 还是 Chrony？

3 节点集群中，任意两节点时钟偏差 > 500ms，Raft 就会拒绝投票。systemd-timesyncd的默认轮询间隔是 2048 秒（约 34 分钟），不够用。决策依据：在所有节点运行chronyc tracking，看Last offset是否 < 10ms。若 > 50ms，必须用chronyc makestep强制校正。生产环境必须禁用systemd-timesyncd：sudo systemctl stop systemd-timesyncd && sudo systemctl disable systemd-timesyncd，再sudo apt install chrony && sudo systemctl enable chrony。

5.5 决策点五：TLS 证书的统一签发——自签名还是 CA 签发？

集群节点间通信默认走明文，但生产环境必须开启 TLS。KaiwuDB 要求所有节点使用同一套 CA 证书签发的证书，不能各自生成自签名证书。决策依据：用openssl x509 -in /opt/kaiwudb/certs/node1.crt -text -noout | grep "Issuer:"查看 issuer，3 个节点的 issuer 必须完全相同。我曾用 OpenSSL 为每个节点单独生成证书，issuer 是各自的 CN，结果节点加入时kaiwudb-server日志报x509: certificate signed by unknown authority，折腾 3 小时才发现是