企业官网建设流程全解析

要是你去过哪怕一个产线的边缘机房，多半见过这种尴尬：单机跑着 KaiwuDB，存储着一堆设备上报的数据，平时看着挺稳，可一旦磁盘坏道、系统崩溃或者整机断电，业务直接就断在那里，所有采集、查询、分析全部哑火。客户不会关心你是运气不好还是硬件老化，他们只知道“数据库挂了”。所以在边缘侧做双节点高可用，几乎是刚需。

我问过不少同行，第一反应都是上 Keepalived 或者分布式存储。但真到现场就会发现，边缘场景的网络带宽有限、机器数量就两台、机柜空间和供电都紧张，云上那套根本搬不过来。后来我把方案收敛到 DRBD + Pacemaker 这对经典组合，配合 KaiwuDB 做一套双节点主备高可用，实际跑了小半年，经历了真实断电、网线松动、内核升级这些折腾，才算把整个方案的脾气摸透了。这篇文章不聊虚的，把我配置的过程、踩过的坑、还有现场故障处理的思路全部放出来，给准备在物联网边缘场景做数据库高可用的同学一个可以直接抄作业的参考。

1. 选型之前：边缘高可用为什么不能照搬云上那套

1.1 边缘机房的“紧约束”

很多搞传统 IT 的人一开始很难理解，为什么明明有成熟的分布式数据库、云原生高可用方案，还要在边缘机房捣鼓两台裸机。真到了现场你就明白了，边缘机房的约束条件完全是另一套逻辑：

第一，机器数量严重受限。边缘侧通常就放两台服务器，甚至有的项目连两台都嫌多，因为柜位、电力、空调、带宽都是算钱的。想搞三节点强一致，客户预算先不答应。

第二，网络条件不稳定。边缘机房和中心机房之间往往是专线甚至 4G/5G 通道，延迟和抖动都很夸张。你要是把 KaiwuDB 的流复制或者分布式一致性协议架在跨公网的链路上，写延迟高到业务没法用。

第三，运维力量薄弱。中心机房有专职 DBA 和运维平台，边缘机房可能连个常驻 IT 都没有，出了问题只能远程处理，甚至是当地电工帮忙看一下供电。方案越简单、越不依赖外部条件，才越靠谱。

所以边缘侧的高可用，本质上要回答一个问题：“在只有两台机器、网络会抖、没人常驻的条件下，怎么让数据库在单机故障时自动换人值班？” DRBD + Pacemaker 这个组合，恰好就是冲着这个问题来的。

1.2 为什么是 DRBD + Pacemaker，而不是分布式存储

一开始我也动过用 Ceph 或者 GlusterFS 的念头，但冷静分析之后放弃了。分布式存储的优势是横向扩展、多副本，但它的前提是多节点、高性能网络、以及足够的磁盘资源。边缘环境两台机器，你整个 Ceph 集群，副本要放哪儿？第三副本放中心机房？跨专线做副本同步，数据一致性会变得一团糟。

DRBD（Distributed Replicated Block Device）走的是完全不同的思路：它不搞对象存储那一套，直接把一块磁盘分区做成镜像，主节点写入的数据通过内核模块实时复制到备用节点的对应磁盘上。在应用层看来，它就是一个普通的块设备，KaiwuDB 根本感知不到底层是单块物理盘还是 DRBD 镜像盘。这种“透明”特性非常重要，意味着数据库本身不需要做任何改造，就能获得一个“看起来像单盘但底层双写”的存储底座。

Pacemaker 负责的是“谁来当主”的问题。它盯住节点存活状态、资源运行状态，一旦检测到主节点故障，就把 VIP、文件系统、数据库服务这些资源整体移到备用节点上。Keepalived 只能漂移 IP，管不了数据库进程是否还活着；Pacemaker 是一整套资源编排框架，可以定义资源的启动顺序、启停约束、故障迁移策略，是真正意义上的“高可用编舞师”。

1.3 这套方案的适用边界

说句公道话，DRBD + Pacemaker 不是银弹，它有非常明确的适用边界。

它擅长解决的是“本地机房的单点故障”，比如电源、主板、磁盘、系统层面挂了，备机可以顶上；但解决不了“机房整体断电”或者“一整条专线断了”这种地域级故障，那得靠跨机房灾备或者异地备份。

另外，数据保护粒度是整块块设备，不是数据库逻辑级的复制。如果你误执行了 DROP TABLE，DRBD 也会把这条操作同步到备机上，然后两边一起“悲剧”。所以它必须搭配常规备份一起用，指望它做误操作恢复是不现实的。

还有一点需要心里有数：故障切换需要时间，正常情况下从故障发生到 KaiwuDB 在新节点上提供服务，几十秒到一两分钟都算常见，具体取决于资源启动脚本的效率和磁盘检查速度。如果你的业务连几十秒都不能接受，那得考虑双写方案，而不是这种主备切换方案。

2. 整体架构与组件分工

2.1 拓扑：一对服务器加两块网卡加一个漂移 IP

我在项目里搭的拓扑非常简单，两台物理服务器，型号和配置尽量完全一致，磁盘接口、内存大小、CPU 型号越接近越好。硬件不一致容易出现“主节点写入了 100 万行数据，备机磁盘慢导致复制延迟”这类问题。

每台机器配了两块网卡：

• 业务网卡（eth0）：对外提供服务，KaiwuDB 的客户端通过浮动 IP 连接。
• 存储同步网卡（eth1）：专走 DRBD 数据复制流量，使用独立的内网 IP 段互通。

为什么强调要独立网卡？因为 DRBD 在 protocol C 模式下，备机每次都要等数据真正落盘后才给主节点回确认，如果复制流量和业务流量挤在同一块网卡上，高峰期互相抢带宽，写延迟会明显变大。我曾经偷懒把 DRBD 跑在业务网卡上，结果上午九点设备批量上报时，数据库提交延迟从 2ms 直接飙到 40ms，后来乖乖加了一块网卡才恢复。

两台机器之间还配了一条额外的直连网线作为冗余通道（可选），如果主交换机上联口出问题，DRBD 的 replication 链路不至于立刻断掉，能多一层保障。

拓扑上还有一个关键角色：浮动 IP（VIP），比如 192.168.10.100。客户端配置连接这个 IP，而不是直连某台物理机的固定 IP。平时 VIP 落在主节点上，主节点故障后，Pacemaker 把 VIP 漂移到备节点，客户端感受不到 IP 变化。

2.2 资源分工：谁管盘、谁管服务、谁管入口

整个高可用方案里有三类资源，分工非常明确：

• DRBD 资源负责提供“两块盘”，它决定哪个节点当前持有主份镜像。
• 文件系统资源负责把 DRBD 块设备挂载到指定目录（例如 /var/lib/kaiwudb），只有主节点才有权挂载。
• 数据库服务资源负责拉起和监控 KaiwuDB 进程，VIP 资源负责让外部客户端找到数据库。

这三者的依赖关系是个严格的链条：必须先提升 DRBD 主节点，才能挂载文件系统；文件系统挂载成功后，才能启动 VIP；VIP 生效后，KaiwuDB 服务才能对外启动接收连接。Pacemaker 的约束配置就是用来固定这个链条顺序的，如果顺序颠倒，数据库起来的时候数据目录不存在，连接请求全失败。

2.3 版本选型与内核前提

这套方案对系统的要求不高，但我实测下来有几个版本层面的经验：

• 操作系统：我在生产环境用的是 CentOS Stream 8 / Rocky Linux 8，内核版本 4.18 以上，DRBD 模块兼容性很好。
• DRBD：9.x 系列管理起来更友好，但 8.4 的稳定性和文档成熟度也很高。我用的是 DRBD 9.2 + 对应版本的 drbd-utils。
• Pacemaker：2.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 同步网卡互通，比如：

• 节点 A：192.168.10.11
• 节点 B：192.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.res：

resource 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-rate=50M r0

50M 是每秒同步速率上限，具体数值根据磁盘能力和业务空闲程度灵活调整。

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/s，2TB 数据差不多三个多小时同步完。如果你的网络只有千兆，建议设置在 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、5406（UDP）和 21064（TCP），pcsd 监听 2224 端口。现场部署时经常遇到“节点状态显示 offline”，排查了一圈发现是防火墙默认规则没放行这些端口。直接放行：

firewall-cmd --permanent --add-service=high-availability firewall-cmd --permanent --add-port=5404-5406/udp firewall-cmd --permanent --add-port=21064/tcp firewall-cmd --reload

4.2 注册 DRBD 资源为可提升资源

DRBD 在 Pacemaker 里要注册成“可提升的克隆资源”（promotable clone），意思是在两个节点上都运行一个 DRBD 实例，但只有一个被提升为 Primary，另一个保持 Secondary。配置命令：

pcs resource create drbd_r0 ocf:linbit:drbd drbd_resource=r0 \ promoted-max=1 promoted-node-max=1 clone-max=2 clone-node-max=1 \ notify=true monitor interval=30s

这里每个参数都有讲究：promoted-max=1确保整个集群里最多只有一个 Primary 节点，否则两边同时写入会出现数据分叉；promoted-node-max=1保证同一个节点也只提升一次；notify=true是让 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 fstype=ext4 \ directory=/var/lib/kaiwudb

然后创建 VIP 资源：

pcs resource create vip_kaiwu IPaddr2 ip=192.168.10.100 cidr_netmask=24

再创建 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 INFINITY

INFINITY是强制约束，意思是 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-policy=ignore

这个选项的含义是：没有法定人数时不自动停资源，把仲裁职责“交给上层决策”。在双节点主备场景下，这个策略是实际可用的，但代价是失去了 quorum 层面的防脑裂保护，必须依赖 STONITH 或者手动介入来兜底。

再来说 STONITH（Shoot The Other Node In The Head）。它的作用是当节点间通信中断时，把对方物理断电或重启，防止两个节点同时认为自己是主。如果服务器带 IPMI/BMC，最标准的是配置fence_ipmilan：

pcs stonith create ipmi-fence fence_ipmilan pcmk_host_list="edge-node-1 edge-node-2" \ ipaddr=192.168.10.201 login=admin passwd=xxx lanplus=1

没有 IPMI 的情况下，我一般会明确告诉团队：“当前环境没有硬件 fence 能力，只能设置 stonith-enabled=false，换取故障时剩余节点能继续提供服务的可用性，同时必须接受脑裂时可能产生的数据冲突风险。” 这不是个完美的答案，但在边缘硬件条件受限时属于工程上的务实取舍。

pcs property set stonith-enabled=false

记住，关掉 STONITH 不代表没有脑裂防护，DRBD 自身的fencing resource-only配置和人工巡检依然能兜底，只是防护强度从“自动物理隔离”降级到了“半自动标记隔离”。这个账要跟业务方说清楚。

5. KaiwuDB 接入与首次切换验证

5.1 数据目录规划与挂载点选择

KaiwuDB 的数据目录默认路径随安装包而定，我在生产环境里统一规划成/var/lib/kaiwudb，让 DRBD 的挂载点也指向这里。这样结构非常清晰：DRBD 提供/dev/drbd0，文件系统资源把它挂到/var/lib/kaiwudb，KaiwuDB 的配置文件里只要把数据目录指定到这里即可。

注意安装 KaiwuDB 时不要让它自动启动，否则两台机器开机都会拉起数据库，和 Pacemaker 抢资源所有权：

systemctl disable kaiwudb systemctl stop kaiwudb

这一步非常关键。Pacemaker 管理的资源必须独占启动权，系统自启的数据库服务会让集群状态变得混乱，出现“节点还在启动中，数据库却已经占用数据目录”的冲突。

5.2 编写 KaiwuDB 的启动脚本与 systemd 单元

KaiwuDB 安装完成后，自己写一个kaiwudb.service，内容大致如下：

[Unit] Description=KaiwuDB Database Server After=network.target [Service] User=kaiwu Group=kaiwu ExecStart=/opt/kaiwudb/bin/kaiwudb -D /var/lib/kaiwudb ExecReload=/bin/kill -HUP $MAINPID Restart=no LimitNOFILE=65535 [Install] WantedBy=multi-user.target

这里我特意把Restart=no，因为在高可用集群里，进程重启策略应该由 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 个坑

把这个方案从零到上线，踩过的坑不少，我把最有代表性的几个整理成了一张速查表，方便后来者直接对照：

6.2 脑裂的识别与恢复流程

脑裂是双节点高可用最怕的故障，但恰恰是现场最容易发生的。表现是两台机器之间的 DRBD 同步链路断开，但两台机器本身都没挂，Pacemaker 的 quorum 机制又因为票数不足无法裁决，两边可能都想抢主角色。

识别脑裂的第一动作是看drbdadm status r0，如果出现SplitBrain或者WFConnection状态，再看/var/log/drbd.log里的连接断开时间点。在这个阶段，千万不要直接在两台机器上同时执行drbdadm primary，那不是恢复，那是在制造灾难。

正确的恢复流程是：

1. 确定哪边的数据要保留。一般看两边 KaiwuDB 服务当前是否还在运行，以及两边数据目录最新的 WAL 时间戳，选时间戳新的一方作为保留数据方。
2. 在需要丢弃数据的节点上执行：

drbdadm secondary --force r0 drbdadm disconnect r0 drbdadm connect --discard-my-data r0

3. 在保留数据方执行：

drbdadm connect r0

4. 等同步完成后确认两端状态都为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 纯属给自己找事。生产环境的可靠性，很多时候是靠“少一点”赢来的。