要是你去过哪怕一个产线的边缘机房多半见过这种尴尬单机跑着 KaiwuDB存储着一堆设备上报的数据平时看着挺稳可一旦磁盘坏道、系统崩溃或者整机断电业务直接就断在那里所有采集、查询、分析全部哑火。客户不会关心你是运气不好还是硬件老化他们只知道“数据库挂了”。所以在边缘侧做双节点高可用几乎是刚需。我问过不少同行第一反应都是上 Keepalived 或者分布式存储。但真到现场就会发现边缘场景的网络带宽有限、机器数量就两台、机柜空间和供电都紧张云上那套根本搬不过来。后来我把方案收敛到 DRBD Pacemaker 这对经典组合配合 KaiwuDB 做一套双节点主备高可用实际跑了小半年经历了真实断电、网线松动、内核升级这些折腾才算把整个方案的脾气摸透了。这篇文章不聊虚的把我配置的过程、踩过的坑、还有现场故障处理的思路全部放出来给准备在物联网边缘场景做数据库高可用的同学一个可以直接抄作业的参考。1. 选型之前边缘高可用为什么不能照搬云上那套1.1 边缘机房的“紧约束”很多搞传统 IT 的人一开始很难理解为什么明明有成熟的分布式数据库、云原生高可用方案还要在边缘机房捣鼓两台裸机。真到了现场你就明白了边缘机房的约束条件完全是另一套逻辑第一机器数量严重受限。边缘侧通常就放两台服务器甚至有的项目连两台都嫌多因为柜位、电力、空调、带宽都是算钱的。想搞三节点强一致客户预算先不答应。第二网络条件不稳定。边缘机房和中心机房之间往往是专线甚至 4G/5G 通道延迟和抖动都很夸张。你要是把 KaiwuDB 的流复制或者分布式一致性协议架在跨公网的链路上写延迟高到业务没法用。第三运维力量薄弱。中心机房有专职 DBA 和运维平台边缘机房可能连个常驻 IT 都没有出了问题只能远程处理甚至是当地电工帮忙看一下供电。方案越简单、越不依赖外部条件才越靠谱。所以边缘侧的高可用本质上要回答一个问题“在只有两台机器、网络会抖、没人常驻的条件下怎么让数据库在单机故障时自动换人值班” DRBD Pacemaker 这个组合恰好就是冲着这个问题来的。1.2 为什么是 DRBD Pacemaker而不是分布式存储一开始我也动过用 Ceph 或者 GlusterFS 的念头但冷静分析之后放弃了。分布式存储的优势是横向扩展、多副本但它的前提是多节点、高性能网络、以及足够的磁盘资源。边缘环境两台机器你整个 Ceph 集群副本要放哪儿第三副本放中心机房跨专线做副本同步数据一致性会变得一团糟。DRBDDistributed Replicated Block Device走的是完全不同的思路它不搞对象存储那一套直接把一块磁盘分区做成镜像主节点写入的数据通过内核模块实时复制到备用节点的对应磁盘上。在应用层看来它就是一个普通的块设备KaiwuDB 根本感知不到底层是单块物理盘还是 DRBD 镜像盘。这种“透明”特性非常重要意味着数据库本身不需要做任何改造就能获得一个“看起来像单盘但底层双写”的存储底座。Pacemaker 负责的是“谁来当主”的问题。它盯住节点存活状态、资源运行状态一旦检测到主节点故障就把 VIP、文件系统、数据库服务这些资源整体移到备用节点上。Keepalived 只能漂移 IP管不了数据库进程是否还活着Pacemaker 是一整套资源编排框架可以定义资源的启动顺序、启停约束、故障迁移策略是真正意义上的“高可用编舞师”。1.3 这套方案的适用边界说句公道话DRBD Pacemaker 不是银弹它有非常明确的适用边界。它擅长解决的是“本地机房的单点故障”比如电源、主板、磁盘、系统层面挂了备机可以顶上但解决不了“机房整体断电”或者“一整条专线断了”这种地域级故障那得靠跨机房灾备或者异地备份。另外数据保护粒度是整块块设备不是数据库逻辑级的复制。如果你误执行了 DROP TABLEDRBD 也会把这条操作同步到备机上然后两边一起“悲剧”。所以它必须搭配常规备份一起用指望它做误操作恢复是不现实的。还有一点需要心里有数故障切换需要时间正常情况下从故障发生到 KaiwuDB 在新节点上提供服务几十秒到一两分钟都算常见具体取决于资源启动脚本的效率和磁盘检查速度。如果你的业务连几十秒都不能接受那得考虑双写方案而不是这种主备切换方案。2. 整体架构与组件分工2.1 拓扑一对服务器加两块网卡加一个漂移 IP我在项目里搭的拓扑非常简单两台物理服务器型号和配置尽量完全一致磁盘接口、内存大小、CPU 型号越接近越好。硬件不一致容易出现“主节点写入了 100 万行数据备机磁盘慢导致复制延迟”这类问题。每台机器配了两块网卡业务网卡eth0对外提供服务KaiwuDB 的客户端通过浮动 IP 连接。存储同步网卡eth1专走 DRBD 数据复制流量使用独立的内网 IP 段互通。为什么强调要独立网卡因为 DRBD 在 protocol C 模式下备机每次都要等数据真正落盘后才给主节点回确认如果复制流量和业务流量挤在同一块网卡上高峰期互相抢带宽写延迟会明显变大。我曾经偷懒把 DRBD 跑在业务网卡上结果上午九点设备批量上报时数据库提交延迟从 2ms 直接飙到 40ms后来乖乖加了一块网卡才恢复。两台机器之间还配了一条额外的直连网线作为冗余通道可选如果主交换机上联口出问题DRBD 的 replication 链路不至于立刻断掉能多一层保障。拓扑上还有一个关键角色浮动 IPVIP比如 192.168.10.100。客户端配置连接这个 IP而不是直连某台物理机的固定 IP。平时 VIP 落在主节点上主节点故障后Pacemaker 把 VIP 漂移到备节点客户端感受不到 IP 变化。2.2 资源分工谁管盘、谁管服务、谁管入口整个高可用方案里有三类资源分工非常明确DRBD 资源负责提供“两块盘”它决定哪个节点当前持有主份镜像。文件系统资源负责把 DRBD 块设备挂载到指定目录例如 /var/lib/kaiwudb只有主节点才有权挂载。数据库服务资源负责拉起和监控 KaiwuDB 进程VIP 资源负责让外部客户端找到数据库。这三者的依赖关系是个严格的链条必须先提升 DRBD 主节点才能挂载文件系统文件系统挂载成功后才能启动 VIPVIP 生效后KaiwuDB 服务才能对外启动接收连接。Pacemaker 的约束配置就是用来固定这个链条顺序的如果顺序颠倒数据库起来的时候数据目录不存在连接请求全失败。2.3 版本选型与内核前提这套方案对系统的要求不高但我实测下来有几个版本层面的经验操作系统我在生产环境用的是 CentOS Stream 8 / Rocky Linux 8内核版本 4.18 以上DRBD 模块兼容性很好。DRBD9.x 系列管理起来更友好但 8.4 的稳定性和文档成熟度也很高。我用的是 DRBD 9.2 对应版本的 drbd-utils。Pacemaker2.1.x 以上版本corosync 3.x 配套。KaiwuDB能跑在标准 Linux 上就行我们用的是它的 x86_64 版本。还有一点容易被忽视内核需要加载 drbd 模块。如果是自编译内核编译选项里必须勾上CONFIG_BLK_DEV_DRBD。我遇到过用官方最小化系统装的时候模块不在后来装了kmod-drbd包才解决。装完之后记得手动执行一次modprobe drbd确认没有报错。3. DRBD 部署让两台机器共用一块“虚拟盘”3.1 准备块设备、加载内核模块DRBD 需要的是“裸块设备”也就是一块没做过文件系统、没参与 LVM 卷组的分区或整个磁盘。我用的是每台机器的第二块数据盘/dev/sdb1在安装系统时就把这块盘留白只分区不格式化。先确认两台机器都能加载模块modprobe drbd lsmod | grep drbd如果提示找不到模块说明内核模块没装需要先安装对应内核版本的kmod-drbd包。接着给两台机器设置固定的内网 IP确保 DRBD 同步网卡互通比如节点 A192.168.10.11节点 B192.168.10.12然后修改/etc/drbd.d/global_common.conf这是全局配置两台机器内容一致global { usage-count no; } common { net { protocol C; cram-hmac-alg sha1; shared-secret kaiwu-edge-secret; max-buffers 8192; sndbuf-size 1M; } disk { fencing resource-only; } }protocol C必须强调一下这是 DRBD 三种复制协议里最严格的一种主节点必须等待备机把数据真正写入磁盘后才向应用层返回写成功。边缘高可用场景要的就是“数据不丢”其他协议都别考虑。fencing resource-only的意思是当发生脑裂时备用节点会尝试触发 fence 动作确保主节点不会继续分裂写入。实际实现依赖 Pacemaker 配合不能脱离集群单独生效。3.2 配置文件里的资源定义接下来定义 DRBD 资源文件/etc/drbd.d/r0.resresource r0 { device /dev/drbd0; meta-disk internal; on edge-node-1 { disk /dev/sdb1; address 192.168.10.11:7788; } on edge-node-2 { disk /dev/sdb1; address 192.168.10.12:7788; } }meta-disk internal表示元数据放在块设备本身尾部这样配置最简单不需要单独划分一个 meta 分区。address后面的端口 7788 是 DRBD 的默认数据同步端口注意在防火墙里放行别把这条链路的端口给挡了。如果你用 DRBD 9.x配置文件里还能加connection和path这些高级选项比如配置多路径、多网卡冗余但基础的主从配置用上面这份就够。3.3 初始化元数据并完成首次全量同步在两台机器上都执行drbdadm create-md r0 drbdadm up r0第一次执行create-md会往磁盘写入 DRBD 元数据这个过程虽然快但做过之后原来的分区数据就不可直接读取了。所以这一步一定要确认/dev/sdb1是空盘或者里面的数据已经不需要了。然后选择其中一台作为初始主节点我先用 edge-node-1执行drbdadm primary --force r0--force参数只在初始建主的时候用因为此时两台设备还处于“无主”的断开状态不加 force 系统会拒绝直接提升。然后格式化并临时挂载mkfs.ext4 /dev/drbd0 mount /dev/drbd0 /mnt格式化只需要在主节点做一次DRBD 会把格式化产生的数据同步到备机的磁盘上。接着看同步状态cat /proc/drbd drbdadm status r0正常情况下会看到类似SyncSource或sync状态的进度百分比。初次全量同步期间磁盘 IO 占用很猛如果两边盘没有做 RAID 或者用的还是机械盘建议限速避免把业务 IO 拖垮drbdadm connect -- --resync-rate50M r050M 是每秒同步速率上限具体数值根据磁盘能力和业务空闲程度灵活调整。3.4 关于同步速度与性能调优的实操心得第一次做全量同步我盯着进度条看了整整四个多小时两台机器各 2TB 的盘默认的 resync-rate 太保守一开始没设限速反而快不了。后来发现DRBD 的同步效率受限于几个参数resync-rate、al-extents、c-plan-ahead和disk-barrier。resync-rate每秒同步多少数据不影响正常业务时的复制性能只在当前掉线后重新连接时需要。al-extents活动的日志 extent 数量默认 127对一般数据库场景够用不需要动。c-plan-ahead动态同步算法的预判时间默认值在慢速网络下偏保守。我实际生产中用 10G 内网互联全量同步速度上限设到 200M/s2TB 数据差不多三个多小时同步完。如果你的网络只有千兆建议设置在 80M~100M不然带宽全被同步吃了业务查询卡成狗。还有个细节很多人不知道DRBD 对底层磁盘的写缓存很敏感如果磁盘开启了带易失缓存的写模式掉电时可能丢数据。有条件的话给两块数据盘配上带电容掉电保护的 SSD或者至少确认磁盘控制器启用了 write-back cache 并且有电池保护否则在金融级场景里这会让整个方案的可信度掉一大截。4. Pacemaker 集群编排把故障切换变成一套“服务编排”4.1 Corosync 通信配置与集群初始化DRBD 本身只会做数据复制它不会决定到底谁当主、什么时候切换、服务要不要跟着起来这些决策都是 Pacemaker 的活。Pacemaker 底层依赖 Corosync 做节点间通信它负责维护成员关系、发心跳、选举负责人。我用的发行版仓库里自带 Pacemaker 和 Corosync安装后第一件事是设置集群用户密码dnf install -y pcs pacemaker corosync fence-agents-all resource-agents systemctl enable --now pcsd passwd hacluster然后两边互相认证并创建集群pcs host auth edge-node-1 edge-node-2 -u hacluster pcs cluster setup kaiwu-cluster edge-node-1 edge-node-2 pcs cluster start --all系统会要求输入之前给hacluster设置的密码。集群配置好后pcs cluster status应该能看到两个节点都在线。这里有个关键点Corosync 的通信端口包括 5404、5405、5406UDP和 21064TCPpcsd 监听 2224 端口。现场部署时经常遇到“节点状态显示 offline”排查了一圈发现是防火墙默认规则没放行这些端口。直接放行firewall-cmd --permanent --add-servicehigh-availability firewall-cmd --permanent --add-port5404-5406/udp firewall-cmd --permanent --add-port21064/tcp firewall-cmd --reload4.2 注册 DRBD 资源为可提升资源DRBD 在 Pacemaker 里要注册成“可提升的克隆资源”promotable clone意思是在两个节点上都运行一个 DRBD 实例但只有一个被提升为 Primary另一个保持 Secondary。配置命令pcs resource create drbd_r0 ocf:linbit:drbd drbd_resourcer0 \ promoted-max1 promoted-node-max1 clone-max2 clone-node-max1 \ notifytrue monitor interval30s这里每个参数都有讲究promoted-max1确保整个集群里最多只有一个 Primary 节点否则两边同时写入会出现数据分叉promoted-node-max1保证同一个节点也只提升一次notifytrue是让 DRBD 在提升/取消提升前收到通知配合已有的资源做顺序切换。注册之后先不要急着建其他资源先确认pcs status里能看到drbd_r0的 promotable 状态并在其中一个节点上显示 Promoted。如果资源起不来多半是/etc/drbd.d/r0.res的名字和drbd_resource的名字没对上或者 DRBD 还在断开状态用drbdadm status r0看一下底层状态。4.3 Filesystem、VIP 与 KaiwuDB 服务的依赖链DRBD 资源建好后接着创建文件系统资源pcs resource create fs_kaiwu Filesystem device/dev/drbd0 fstypeext4 \ directory/var/lib/kaiwudb然后创建 VIP 资源pcs resource create vip_kaiwu IPaddr2 ip192.168.10.100 cidr_netmask24再创建 KaiwuDB 服务资源。KaiwuDB 本身不提供现成的 Pacemaker 资源代理但我直接用 systemd 单元管理它然后让 Pacemaker 通过systemd资源代理来控制这样最简单也继承了 systemd 的进程管理能力pcs resource create kaiwudb systemd:kaiwudb用这个接口Pacemaker 会自动去调systemctl start/stop/status kaiwudb非常干净。最后用约束把链条锁起来# DRBD 先提升 pcs constraint order promote drbd_r0-clone then start fs_kaiwu pcs constraint colocation add fs_kaiwu with promoted drbd_r0-clone INFINITY # 挂载点优先于 VIP pcs constraint order start fs_kaiwu then start vip_kaiwu # VIP 优先于数据库服务 pcs constraint order start vip_kaiwu then start kaiwudb pcs constraint colocation add kaiwudb with vip_kaiwu INFINITYINFINITY是强制约束意思是 KaiwuDB 必须和 VIP 在同一台机器上VIP 必须在挂载成功的节点上容不得半点含糊。配置完成后整个集群的资源应该在 edge-node-1 上按顺序运行drbd_r0 提升 → 文件系统挂载到 /var/lib/kaiwudb → VIP 绑到 eth0 → KaiwuDB 服务启动。pcs status输出看起来应该是“全绿”的。4.4 双节点中的 quorum 与 stonith 处理双节点集群有个绕不开的问题票数。两个节点各有一票总票数 2法定数按多数算至少需要 2 票。一旦一个节点掉线剩余节点只有 1 票不满足法定多数集群会认为自身失去法定人数从而主动取消所有资源运行。这对高可用来说是很尴尬的因为恰恰是主节点挂了剩下的备机反而不能接管。常见处理方案有几种一是启用 quorum 设备的软仲裁方案比如用额外的第三方仲裁节点可以是中心机房的一台小虚拟机或树莓派参与投票这样剩余两台边缘节点加仲裁节点共有三票任何一台边缘节点挂了剩余两台票数仍有 2满足多数。二是在两节点资源紧张、确实不想加第三方设备时降低 quorum 的要求让集群在剩余单节点时继续提供服务pcs property set no-quorum-policyignore这个选项的含义是没有法定人数时不自动停资源把仲裁职责“交给上层决策”。在双节点主备场景下这个策略是实际可用的但代价是失去了 quorum 层面的防脑裂保护必须依赖 STONITH 或者手动介入来兜底。再来说 STONITHShoot The Other Node In The Head。它的作用是当节点间通信中断时把对方物理断电或重启防止两个节点同时认为自己是主。如果服务器带 IPMI/BMC最标准的是配置fence_ipmilanpcs stonith create ipmi-fence fence_ipmilan pcmk_host_listedge-node-1 edge-node-2 \ ipaddr192.168.10.201 loginadmin passwdxxx lanplus1没有 IPMI 的情况下我一般会明确告诉团队“当前环境没有硬件 fence 能力只能设置 stonith-enabledfalse换取故障时剩余节点能继续提供服务的可用性同时必须接受脑裂时可能产生的数据冲突风险。” 这不是个完美的答案但在边缘硬件条件受限时属于工程上的务实取舍。pcs property set stonith-enabledfalse记住关掉 STONITH 不代表没有脑裂防护DRBD 自身的fencing resource-only配置和人工巡检依然能兜底只是防护强度从“自动物理隔离”降级到了“半自动标记隔离”。这个账要跟业务方说清楚。5. KaiwuDB 接入与首次切换验证5.1 数据目录规划与挂载点选择KaiwuDB 的数据目录默认路径随安装包而定我在生产环境里统一规划成/var/lib/kaiwudb让 DRBD 的挂载点也指向这里。这样结构非常清晰DRBD 提供/dev/drbd0文件系统资源把它挂到/var/lib/kaiwudbKaiwuDB 的配置文件里只要把数据目录指定到这里即可。注意安装 KaiwuDB 时不要让它自动启动否则两台机器开机都会拉起数据库和 Pacemaker 抢资源所有权systemctl disable kaiwudb systemctl stop kaiwudb这一步非常关键。Pacemaker 管理的资源必须独占启动权系统自启的数据库服务会让集群状态变得混乱出现“节点还在启动中数据库却已经占用数据目录”的冲突。5.2 编写 KaiwuDB 的启动脚本与 systemd 单元KaiwuDB 安装完成后自己写一个kaiwudb.service内容大致如下[Unit] DescriptionKaiwuDB Database Server Afternetwork.target [Service] Userkaiwu Groupkaiwu ExecStart/opt/kaiwudb/bin/kaiwudb -D /var/lib/kaiwudb ExecReload/bin/kill -HUP $MAINPID Restartno LimitNOFILE65535 [Install] WantedBymulti-user.target这里我特意把Restartno因为在高可用集群里进程重启策略应该由 Pacemaker 来决策而不是让 systemd 本地无限重启。如果应用崩溃后本地 systemd 立即拉起Pacemaker 可能还没来得及执行故障迁移数据库又“假活”了反而掩盖了问题。如果你希望 Pacemaker 对数据库进程做更细粒度的健康检查也可以自己写一个 OCF 资源代理。但实际维护下来systemd 资源代理已经能满足需求Pacemaker 默认 monitor 间隔 30 秒去检查 systemd 状态30 秒内检测到服务异常就会触发迁移。对边缘场景足够。5.3 故障演练模拟宕机、断网、进程崩溃集群配置完别急着交付我一定建议先做一轮故障演练。不演练的集群等于没装高可用因为你不知道切换流程在哪一环会卡住。演练一正常迁移。在 edge-node-2 上手动停掉集群观察资源是否完整漂移到 edge-node-1。pcs node standby edge-node-2 pcs status这个操作相当于把节点设置为待命状态Pacemaker 会自动把该节点上的所有资源迁移到另一个节点全程不需要人工干预。如果这一步就出现资源卡在某个中间状态说明依赖链配置有误比如 VIP 资源尝试绑定到未启用的网卡或者 KaiwuDB 服务启动脚本里路径写错。演练二模拟主节点进程崩溃。直接在 edge-node-1 上kill -9掉 KaiwuDB 的进程kill -9 $(pgrep -f kaiwudb)Pacemaker 在 30 秒内会检测到 systemd 单元 inactive然后自动尝试本地重启如果重启失败触发迁移。资源依次从 edge-node-1 释放并到 edge-node-2 上重新拉起。整个切换时间取决于磁盘检查和 KaiwuDB 启动耗时我实测大多数情况下 40 秒左右业务恢复。演练三模拟断网/断电。硬关机 edge-node-1确认 edge-node-2 能接管。这一步最真实因为硬关机过程中没有优雅的集群退出流程Corosync 需要靠 token 超时来判定对端失联默认约 10 秒后进入新的法定成员组随后触发资源迁移。整个过程 60 秒到两分钟都算正常取决于 token 超时配置和资源启动速度。5.4 验证客户端连接与数据一致性切换完成后第一时间要做的不是庆祝而是验证数据没丢、服务可用// 在业务机或边端网关上连接数据库 /opt/kaiwudb/bin/ksql -h 192.168.10.100 -p 5432 -U admin先查一下最近写入的几行数据再对比切换前后记录数、最新时间戳。DRBD protocol C 模式下只要切换发生前网络正常且复制没有断流理论上数据是完整的。但保险起见我会在演练脚本里加上“写入-计数-校验”步骤应用侧每秒插入一条带序号的数据故障期间记录中断时间切换后查询最大序号中间空缺的序号就是实际不可用时间。6. 常见问题与踩坑记录6.1 我踩过的 7 个坑把这个方案从零到上线踩过的坑不少我把最有代表性的几个整理成了一张速查表方便后来者直接对照现象原因解决办法双节点同时显示 Primary网络隔离触发脑裂两边各自接管检查 DRBD 连接状态按脑裂恢复流程处理pcs status资源全是 Stopped剩余节点不满足 quorum 被冻结设置no-quorum-policyignore或部署仲裁节点主机重启后 DRBD 无法自动提升未配置 boot 阶段资源接管策略加入drbd-startup和resource-agents开机服务KaiwuDB 目录权限报错挂载点在主备切换后属主变更统一用户 IDchown -R kaiwu:kaiwu /var/lib/kaiwudb切换后数据库启动超慢磁盘 fsck 检查导致挂载参数加nofail有条件用 xfs 或带日志的文件系统两边 DRBD 状态一直WFConnection同步网卡链路或防火墙问题检查内网连通性放行 7788 端口主节点写延迟抖高DRBD 同步链路带宽不足或抖动升级内网到万兆开启sndbuf-size并确认 TCP 窗口6.2 脑裂的识别与恢复流程脑裂是双节点高可用最怕的故障但恰恰是现场最容易发生的。表现是两台机器之间的 DRBD 同步链路断开但两台机器本身都没挂Pacemaker 的 quorum 机制又因为票数不足无法裁决两边可能都想抢主角色。识别脑裂的第一动作是看drbdadm status r0如果出现SplitBrain或者WFConnection状态再看/var/log/drbd.log里的连接断开时间点。在这个阶段千万不要直接在两台机器上同时执行drbdadm primary那不是恢复那是在制造灾难。正确的恢复流程是确定哪边的数据要保留。一般看两边 KaiwuDB 服务当前是否还在运行以及两边数据目录最新的 WAL 时间戳选时间戳新的一方作为保留数据方。在需要丢弃数据的节点上执行drbdadm secondary --force r0 drbdadm disconnect r0 drbdadm connect --discard-my-data r0在保留数据方执行drbdadm connect r0等同步完成后确认两端状态都为UpToDate。这里最核心的一条原则是脑裂恢复不是技术活是业务决策活。选错保留方丢的数据是补不回来的。所以我在现场的标准动作是先冻结脑裂节点上的写入再比较数据新旧最后才动手恢复。6.3 长期运维巡检清单方案上线不是终点运维巡检才是保证方案长期可靠的关键。以下是我每周会跑一遍的巡检命令# 集群健康 pcs status corosync-quorumtool -l # DRBD 状态 drbdadm status r0 cat /proc/drbd | grep -E ro:|ds: # 文件系统与数据库 df -h /var/lib/kaiwudb systemctl status kaiwudb # 日志 tail -n 50 /var/log/messages | grep -i drbd journalctl -u corosync --since 24 hours ago | grep -i error巡检的核心关注点很简单资源是否都在预期节点上DRBD 两端是否 UpToDate有没有反复重启的记录CPU 和磁盘有没有持续的异常占用这三件事没问题集群大概率就是健康的。7. 双节点方案的边界与替换思路聊到这里还是想泼一点冷水。DRBD Pacemaker 是一个非常“古典”但依然可靠的方案可它解决的只是单机故障不是所有高可用问题。我有一次在客户现场对方想把两套机柜放在不同楼层做“高可用”结果发现 DRBD 同步网络跨了楼层交换机中间还夹着几台非管理型交换机链路抖动严重写延迟高到业务报警。最后我建议他们要么拉一对万兆光纤直连要么干脆放弃双机实时复制、改成中心机房集中备份。另外数据安全不能只靠高可用集群。DRBD 同步镜像解决的是“机器挂了数据还在”的问题解决不了“业务逻辑错误导致数据被删”的问题。我强烈建议给 KaiwuDB 同时配上定期逻辑备份比如每天凌晨把数据导出到独立存储或者用 KaiwuDB 自带的备份工具做 dump。高可用不等于数据不丢这两件事是独立的维度。如果你后面节点数能扩到三台以上倒是可以看看 KaiwuDB 原生的分布式能力或者基于 etcd/Consul 的多节点复制方案比 DRBD 这种主备镜像更灵活。但至少在眼前这个“两台裸机、一条专线、一个电工看门”的边缘场景里DRBD Pacemaker 这套组合是我多次对比之后认为性价比最高、行为最可预期、排障成本最低的方案。最后分享一个长期维护才体会到的细节不要为了“看起来专业”给方案加太多装饰。有同事建议我在集群里再加一层 LVS 做负载均衡被我拒绝了——两台机器做高可用的核心诉求是“不丢、能切”不是“高吞吐”。多一层组件就多一层天然故障源Pacemaker 的 VIP 已经解决了入口漂移问题再加 LVS 纯属给自己找事。生产环境的可靠性很多时候是靠“少一点”赢来的。