夜里十一点半运维群弹出一条告警某个边缘站点的KaiwuDB节点连不上了。这个站点之前一直很安静赶到线上排查才发现系统盘被日志和临时文件塞满数据库想落盘都落不了进程直接卡死。从定位到恢复我们折腾了将近三个小时。第二天复盘时大家达成一致——这种不允许断数据的边缘站点不能再用单机硬扛。于是就有了这套方案两台普通服务器本地各插一块盘用DRBD做块级数据镜像用Pacemaker做故障检测、资源调度和自动切换。KaiwuDB作为物联网时序数据库照常跑在本地盘上只是这块“本地盘”底层已经变成了两台机器共同维护的镜像盘。写这篇分享是想把这套方案从选型、部署到故障演练的完整过程讲一遍尤其是那些文档里不会写的坑。1. 边缘机房的现实为什么单机方案撑不住共享存储又不现实1.1 边缘节点的故障往往不是数据库本身的问题先说当时那台机器是怎么挂的。KaiwuDB进程本身没有报错系统也没崩溃就是系统盘满了数据写入持续失败数据库的各种后台线程开始恶性循环日志刷不进去、状态写不进去、连接堆积最后整个实例僵死。这是边缘站点的典型故障模式——绝大多数宕机根本不是数据库内核的问题而是外围环境磁盘满、内存不足、掉电、网卡松动、BMC失联。单机部署时任何一个外围故障都可能演变成数据库事故。另一个常见问题是无人值守。边缘机房通常没有专职运维远程通道还经常不稳定。一旦数据库出问题技术人员要赶过去现场处理几个小时的业务中断是家常便饭。所以边缘场景对高可用的诉求非常朴素机器挂了没关系但数据不能丢服务要能在几十秒内自动恢复。1.2 为什么说共享存储在边缘不现实传统的高可用方案里最经典的是“共享存储 集群软件”数据库的数据文件放在SAN存储或者磁盘阵列上两台服务器通过光纤或SCSI接同一套存储谁接管存储谁启动数据库。这种方案非常成熟但放到边缘站点就很别扭。首先是成本。一台双控制器存储柜的价格可能比站点里两台服务器加起来还贵。其次是部署条件。很多边缘站点的机柜深度、供电、散热都不满足存储设备的要求。运维上也很麻烦存储设备的固件升级、控制器切换、链路故障定位对没有专职存储工程师的站点来说都是额外负担。1.3 数据库自带复制方案在这里为什么不是首选有人会问KaiwuDB是时序数据库为什么不用它自己的复制能力或分布式多副本非要在存储层搞一套这个问题的答案取决于部署环境。如果节点数够多、网络够稳定数据库自带多副本确实是更省的方案。但边缘站点往往只有两台服务器没有跨机房的优质专线。数据库层的复制方案一般依赖日志、账号、节点角色等一堆配置对版本一致性要求高切换时还要小心处理从库落后、半同步状态、脑裂后数据回放等问题。而DRBD Pacemaker这套组合把高可用做在块设备层数据库完全无感。KaiwuDB写数据时它只看到一块普通的本地盘完全不知道对端还有一台机器在做实时镜像。这种透明性是很大的优势——不依赖数据库版本、不依赖具体文件格式、不依赖数据库是否支持某种复制协议。做一个直观的对比方案部署复杂度硬件成本对数据库透明切换时间边缘场景适配度数据库自带主从复制中低否秒级到分钟级一般依赖网络稳定共享SAN 集群软件高极高是秒级差成本高、运维重DRBD Pacemaker中低是秒级到几十秒好双节点即可表格里有个词要敲黑板透明。块级镜像对数据库应用来说是彻底透明的这意味着当KaiwuDB发布新版本、调整存储参数、修改表结构时底层高可用架构完全不需要跟着动。数据库运维和存储高可用这两个维度被解耦了。1.4 一个反直觉的提醒镜像不等于备份既然聊到数据安全必须泼一盆冷水。DRBD的镜像机制只解决“单台机器物理故障”的问题它不解决逻辑错误。如果有人在主节点执行了误删除或者业务程序写入了错误数据DRBD会把这些错误操作原封不动地同步到备机。备机上存的不是“时间点快照”而是“和主节点一模一样的最新状态”。所以这套方案的准确定位是故障转移Failover不是备份。备份仍然要做而且建议把备份放到另外的独立存储或离线介质上。这个认知偏差是我见过不少团队栽跟头的地方。2. DRBD与Pacemaker的角色拆解谁负责数据谁负责决策谁负责兜底2.1 DRBD把“我的盘”变成“我们的盘”DRBD的全称是Distributed Replicated Block Device工作在内核通用块层。它的工作原理可以类比成两个U盘之间的实时同步主节点上每次写入一个数据块DRBD把它通过网络发给备节点备节点落盘成功后才向主节点返回“写入完成”。KaiwuDB的视角里一切照旧。它往/dev/drbd0写数据以为这是一块本地磁盘实际上DRBD在背后完成了双写。这个“透明”是DRBD最大的价值。DRBD有三种同步协议选型时要想清楚协议返回时机数据安全性写入延迟适用场景Protocol A本地落盘即返回备机可能丢失最后一小段数据最低对丢数据不敏感、网络极差Protocol B备机内存收到即返回备机掉电会丢内存中的数据中网络稳定但盘慢Protocol C备机落盘后返回除非双机同时损坏否则不丢最高默认选择边缘场景首选我们在所有站点都用Protocol C。边缘场景数据完整性优先宁可每次写入多等零点几毫秒也不能在故障切换后发现备机上缺了最后一笔写入。时序数据的特点本来就是高频小写入多等一个局域网往返时延完全可接受。DRBD还有一个关键概念叫活动日志Activity Log。它在盘上维护一块元数据区记录哪些数据块正处于“已写入但尚未同步完成”的状态。这样即使复制过程中断电重启后DRBD也能精确知道哪些块需要重新同步而不是整盘全量比对。这个机制对边缘站点那种三天两头掉电的环境特别有用。2.2 Pacemaker故障时由谁说了算Pacemaker是整个架构的“大脑”它负责监控节点状态、执行约束、决定资源在哪台机器上运行。和它搭档的是Corosync一个负责集群通信和成员关系维护的组件。简单说Corosync管“谁活着”Pacemaker管“活儿谁干”。Pacemaker把一切要管理的对象都抽象成资源。有三个概念必须理解Primitive资源最基本资源单元比如一个VIP、一个数据库服务进程。Master/Slave资源资源有“主”“备”角色比如DRBD设备在主节点是Primary、备节点是Secondary。约束Constraint资源之间的规则包括顺序约束谁先启动、位置约束谁必须和谁在同一台机器、共置约束禁止在哪些节点运行。这套抽象能力正是双节点高可用的核心。我们可以把KaiwuDB的启动顺序定义成DRBD先变为Primary数据库进程再启动VIP最后漂移。三者必须落在同一台机器上这样整个切换过程就像执行一个脚本而不用靠人工去逐步确认。2.3 Fencing防止“两个人都以为自己是老大”双节点HA有一点经常被忽略脑裂。当两个节点之间的同步网断开时双方都会认为对方已失联都试图接管VIP、启动数据库、挂载DRBD设备。如果两边同时写数据数据文件很快就会错乱。Pacemaker解决脑裂的手段叫STONITH——Shoot The Other Node In The Head字面意思就是“把对面那台机器关机”。在决定接管资源之前先通过带外管理接口IPMI/BMC、智能PDU等把对方断电确保对方不可能再写数据然后自己才上位。这是一个很扎心的工程结论没有fencing的双节点高可用不是高可用而是定时炸弹。节点失联后如果两边都认为自己该接管整个数据层就废了。DRBD虽然有防脑裂的机制但它没有能力把对面机器断电所以STONITH是必须配置的兜底手段。3. 动手前的规划细节两台机器要怎么配网络要怎么分3.1 硬件选型同型号、独立系统盘、数据盘用SSD边缘站点不用上高端服务器但有三个细节值得注意。第一两台机器尽量同品牌同配置。DRBD的复制不要求完全一样但硬件差异过大会导致性能不对称。实际运维中如果主节点比备节点快很多同步链路会持续积压备节点永远追不上一旦切换业务跑在慢机器上体验落差很大。同配置至少能消除这类变量。第二系统盘和数据盘必须物理分开。开头那个故障就是系统盘被日志塞满导致数据库实例崩溃。如果数据盘和系统盘是同一块盘系统盘满会影响数据盘如果分开即使系统盘爆掉DRBD数据盘还能正常工作集群也有时间从容切换。我们通常会再加一层约束系统盘上不放任何数据库相关文件日志、core dump、临时文件全部重定向到独立目录。第三数据盘建议NVMe SSD最好带断电保护。DRBD的Protocol C意味着每次数据写入要落两块盘SSD的写放大是客观存在的。时序数据库的高频小写入加上DRBD会把同一个写请求在两台机器各落一次这对机械盘的随机写性能是致命的。换成带掉电保护的NVMe后实测P99写入延迟下降非常明显。3.2 网络规划业务网和同步网必须隔离双节点HA至少有两条逻辑网络业务网客户端连接VIP的路径承载查询和写入流量。同步网DRBD数据复制 Corosync心跳通信的路径。我们推荐物理上使用独立网卡而不是在同一个网卡上做VLAN隔离。理由很直接如果唯一的网卡或者交换机故障业务和同步同时断开集群立刻进入脑裂判定流程这属于可以避免的风险。网络规划示例用途网段节点A节点B备注业务网192.168.10.0/24192.168.10.11192.168.10.12客户端访问VIP为192.168.10.50同步网192.168.20.0/24192.168.20.11192.168.20.12DRBD端口7788、Corosync、fencing同步网建议至少千兆如果站点写入量很大直接上万兆。别小看这条链路它承载着每笔数据写入的两份流量是整套架构的吞吐瓶颈。3.3 软件版本内核模块和DRBD版本必须匹配这个坑在安装阶段就会遇到。DRBD由内核模块和用户态工具两部分组成内核模块必须能加载进当前内核。如果用发行版自带的仓库drbd-utils和kmod-drbd通常会配套维护问题不大。但如果自己编译内核或者升级过内核就要重新确认模块版本。Pacemaker和Corosync我们直接用发行版仓库的版本pcs作为命令行工具来管理集群。版本选择上不需要追新稳定优先。整个项目跑下来我的体会是高可用这套东西最怕的不是功能缺而是多个组件之间版本不匹配导致的诡异行为。4. 完整部署过程从裸机到KaiwuDB自动切换4.1 系统基础配置两台节点都要做先把主机名、hosts、时间同步配好。# 节点A hostnamectl set-hostname node-a # 节点B hostnamectl set-hostname node-b # 两台都执行写入hosts cat /etc/hosts EOF 192.168.10.11 node-a 192.168.10.12 node-b EOF # 配置NTP确保两台机器时间尽量同步 timedatectl set-ntp yes时间同步很容易被忽视但对时序数据库来说很重要。KaiwuDB写入的数据都带时间戳如果主备节点时间偏差太大切换后部分数据的时间戳会显得错乱。DRBD本身对时钟没那么敏感但数据库层面一定要求统一时间基准。防火墙和SELinux按环境选择生产环境不建议直接关闭至少要放行以下端口# 放行常用端口具体以你的发行版为准 firewall-cmd --permanent --add-port7788/tcp # DRBD firewall-cmd --permanent --add-port2224/tcp # pcsd firewall-cmd --permanent --add-port5404/udp # Corosync firewall-cmd --permanent --add-port5405/udp # Corosync firewall-cmd --reload如果站点内没有其他安全设备测试阶段也可以先关闭防火墙等链路跑通后再精细放行。4.2 创建DRBD资源并完成首次同步安装依赖包并加载内核模块yum install -y drbd-utils kmod-drbd modprobe drbd lsmod | grep drbd在/etc/drbd.d/r0.res里定义资源。这是一个最小化配置resource r0 { protocol C; on node-a { device /dev/drbd0; disk /dev/sdb; address 192.168.20.11:7788; meta-disk internal; } on node-b { device /dev/drbd0; disk /dev/sdb; address 192.168.20.12:7788; meta-disk internal; } }注意两点disk /dev/sdb是我这边的盘符示例请务必确认你机器上的盘符。这一步写错DRBD会直接把盘上的原有数据覆盖掉。meta-disk internal表示元数据区放在磁盘最前面的一段空间这是DRBD自己管理的不需要单独分区。初始化并启动# 两台节点都执行 drbdadm create-md r0 drbdadm up r0 # 在node-a上设为Primary并格式化文件系统 drbdadm primary --force r0 mkfs.xfs /dev/drbd0 mkdir -p /data/kaiwu mount /dev/drbd0 /data/kaiwu首次同步时可以通过cat /proc/drbd观察进度。同步期间Secondary节点会从0%一点点涨到100%这个阶段不要急着跑业务因为大量磁盘IO会被复制流量占满。watch -n1 cat /proc/drbd4.3 搭建Pacemaker/Corosync集群安装并启动服务yum install -y pacemaker corosync pcs systemctl enable --now pcsd # 设置hacluster用户密码两台都执行 echo hacluster:你的密码 | chpasswd在node-a上认证并建集群pcs host auth node-a node-b -u hacluster -p 你的密码 pcs cluster setup edge-cluster node-a node-b pcs cluster start --all pcs cluster enable --all pcs status正常情况下pcs status会显示两个节点都已在线。如果节点迟迟没有online优先检查firewall和Corosync端口其次是节点名和hosts的对应关系。4.4 定义Pacemaker资源DRBD、KaiwuDB、VIP资源定义是整个部署的核心思路是先DRBD、后KaiwuDB、再VIP三条约束保证它们永远在同一个节点上。先声明DRBD的Master/Slave资源。Pacemaker会自动为主节点分配Primary角色为备节点分配Secondary角色pcs resource create drbd_r0 ocf:heartbeat:drbd drbd_resourcer0 \ op monitor interval15s roleMaster \ op monitor interval20s roleSlave pcs resource promotable drbd_r0 master-max1 master-node-max1把KaiwuDB包装成systemd服务。这里有个经验Restartno必须设置否则systemd和Pacemaker会同时尝试重启进程出现“两个主管抢一个工人”的局面。cat /etc/systemd/system/kaiwu.service EOF [Unit] DescriptionKaiwuDB Server Afternetwork.target [Service] Userkaiwu Groupkaiwu ExecStart/opt/kaiwudb/bin/kaiwu-server --config /data/kaiwu/kaiwudb.conf Restartno [Install] WantedBymulti-user.target EOF注意ExecStart里的启动命令按实际安装路径调整。KaiwuDB的启动方式如果官方提供了独立脚本也可以在这里调用脚本。用Pacemaker接管这个服务并创建VIP资源pcs resource create kaiwu ocf:heartbeat:systemd unitkaiwu \ op monitor interval15s timeout30s \ op start timeout60s op stop timeout60s pcs resource create vip_r0 ocf:heartbeat:IPaddr2 \ ip192.168.10.50 cidr_netmask24 \ op monitor interval10s最后加约束。关键就是这三条# KaiwuDB和VIP必须跟着DRBD的主节点走 pcs constraint colocation add kaiwu with drbd_r0-clone INFINITY pcs constraint colocation add vip_r0 with drbd_r0-clone INFINITY # 启动顺序DRBD先就绪再启动KaiwuDB最后VIP漂移 pcs constraint order drbd_r0-clone then kaiwu pcs constraint order kaiwu then vip_r0启动顺序里让VIP最后漂移是为了避免出现“VIP已经能连通但数据库还没起来”的半可用状态。客户端连接VIP时如果数据库没就绪只会得到一堆无用的连接失败。4.5 配置Fencing这台机器失联时必须有办法把它断电我们站点用的是带BMC的服务器直接配置IPMI fencingpcs stonith create fence-node-a fence_ipmilan \ pcmk_host_listnode-a ipaddr192.168.10.250 lanplus1 \ useridadmin passwdsecret pcs stonith create fence-node-b fence_ipmilan \ pcmk_host_listnode-b ipaddr192.168.10.251 lanplus1 \ useridadmin passwdsecret pcs property set stonith-enabledtrue如果你的边缘设备没有BMC比较现实的选择是智能PDU电源插排fence_power或者用SBD watchdog实现软件方式的本地自锁。无论选哪种核心思想一样在接管资源前确保另一台机器不可能再写入数据。4.6 迁移KaiwuDB数据并验证切换先把已有KaiwuDB数据迁移到DRBD挂载点上再启动集群资源# 先确认KaiwuDB已停止再复制数据 rsync -av /var/lib/kaiwu/ /data/kaiwu/ # 启动全集群资源Pacemaker会自动安排节点 pcs resource enable --all pcs status这里我用rsync而不是scp是因为数据传输过程一旦中断rsync可以断点续传scp只会留下一个残缺的文件。第一次迁移数据量不会小这个细节能省很多重传时间。迁移完成后手动测试一下切换是否正常。最简单的验证命令是直接在某节点上重启Pacemakerpcs cluster stop node-a几秒后观察pcs status如果vip_r0和kaiwu资源都迁移到了node-b且KaiwuDB能正常对外提供服务这套链路基本就通了。5. 故障演练结果断电、断网、杀进程时系统会怎么反应5.1 演练设计我们做过的演练覆盖三类最常见故障故障类型模拟方法预期行为数据库进程异常kill -9 kaiwu-server 进程资源健康检查失败Pacemaker拉起进程连续失败则整体切换主节点断电直接poweroff心跳超时STONITH触发备机接管VIP并启动数据库同步网断开关闭同步网口触发脑裂检测STONITH隔离失联方存活节点接管5.2 主节点断电切换时间大概在20到40秒实测最顺利的切换路径是主节点直接断电。整个过程大致是Corosync心跳超时认定node-a失联Pacemaker先触发STONITH等fencing确认node-a已经断电后在node-b上把DRBD提升为Primary挂载数据盘拉起KaiwuDBVIP切换。我们站点的实测恢复时间在20到40秒之间。这个时间主要花在fencing动作和数据库进程启动上。如果KaiwuDB启动要回放大量WAL日志时间会更长。想让切换更快可以把Pacemaker的monitor interval调短、failure-timeout调小但不要过度激进——探测间隔太短会把正常的网络抖动误判为节点故障反而频繁触发切换。5.3 同步网断开脑裂恢复流程必须手动同步网断开是最难处理的故障因为它没有“胜者”两边都会认为自己是健康的。我们演练时的现象是两个节点几乎同时把DRBD置为StandAlone状态主动断开复制连接防止双写。恢复脑裂的操作流程比较固定但要先判断哪边数据更新。判断依据可以看/proc/drbd里的复制完成进度、磁盘时间戳以及数据库日志最后写入位置。假设node-b是数据较新的一方# 在node-b要保留数据的一方 drbdadm disconnect r0 drbdadm primary r0 # 在node-a需要丢弃本地数据的一方 drbdadm secondary -- --discard-my-data r0 drbdadm connect r0 # 最后回到node-b重新连接 drbdadm connect r0--discard-my-data这个参数非常危险它表示“我相信对方的数据我本地的数据可以直接丢弃”。执行前务必确认哪边数据较新否则会把新数据抹掉。恢复完DRBD连接后让Pacemaker重新接管资源整个集群就回到正常状态。5.4 数据一致性验证切换后一定要做数据完整性校验。我们在演练中的做法是在DRBD跨节点阻塞写请求的情况下对比/data/kaiwu下关键数据文件的校验和同时检查KaiwuDB日志是否有异常回放记录。如果发现文件校验和不一致优先排查DRBD是否处于完全同步状态再检查是否发生过脑裂后的人为误判。DRBD本身会通过活动日志和元数据区保证断电恢复时的一致性实际运行中只要Protocol C配置正确、同步链路没有长期中断数据文件校验和应该是完全一致的。6. 维护过程中踩过的几个坑6.1 首次同步时跑业务导致复制中断进入StandAlone有次我们新装了一个站点为了节省时间在DRBD还没完成首次全量同步时就把KaiwuDB启动起来接业务流量了。结果同步流量和业务IO抢带宽DRBD连接反复超时最后两端都进入StandAlone状态。根因是首次同步的syncer速率没有限制同时业务写入量又大同步网被打满。后来我们在资源文件里显式限制同步速率syncer { rate 200M; }经验是首次同步期间不要急着挂业务除非你能精确控制同步带宽和业务流量的比例。6.2 内核升级后DRBD模块加载失败有一次例行安全更新重启后DRBD起不来modprobe drbd直接报错。查了半天是内核升级到了新版本但kmod-drbd还是旧版本模块和内核API不匹配。从那之后我们把内核升级和DRBD模块升级绑定在一起升级前先在测试机验证升级后第一时间确认modprobe drbd cat /proc/drbd发行版仓库如果提供了Dynamic Kernel Module SupportDKMS版本建议用DKMS内核升级后模块会自动重新编译。6.3 systemd和Pacemaker抢着重启进程前面提过Restartno这里展开说。如果KaiwuDB服务在systemd unit里配置了Restartalways而Pacemaker同时也在监控它那么进程一旦异常退出systemd立刻拉起进程Pacemaker检测到的可能是一个正在初始化的新进程于是判定“资源还活着不需要切换”。这看起来是好事实际上很危险。如果进程陷入反复崩溃-重启的循环两台机器的监控状态会非常混乱。最终可能演变成systemd在node-a上反复拉起进程Pacemaker因为一直看到进程存活而不切换而客户端实际已经连接不上了。解决方案就是Restartno把进程拉起这件事完全交给Pacemaker由它根据健康检查结果决定是重启进程还是切换节点。6.4 PCS约束改了不生效旧约束还在起作用有次调整VIP的启动顺序改了约束后测试发现VIP还是在数据库之前漂移。查了半天发现是旧的约束配置仍然存在pcs constraint order新增了一条但没有删除旧的那条。两条约束互相冲突Pacemaker选择了更保守的优先级。排查命令pcs constraint list --full pcs config show --full修改约束后记得重新验证不要只盯着新增的配置。Pacemaker的配置是增量生效的旧规则不清理新规则很可能被“叠加”到旧规则之上。6.5 系统盘满连带数据库IO异常这个坑在开头出现过。很多边缘节点会跑监控agent、日志采集、临时脚本这些都可能把系统盘写满。系统盘一旦满了即使数据盘还有空间数据库也会因为写临时文件、写日志失败而卡死。我们在所有边缘站点加了系统盘使用率告警阈值设为85%并确保数据库的临时目录、日志目录全部落在独立的数据盘上。另外定期清理旧的安装包、监控agent的日志文件都是边缘节点必须做的常规维护。7. 这套方案的使用边界与选型建议讲了这么多优点也得说说它不适合哪些场景。首先这套方案不支持双写并发。DRBD的Primary/Secondary模型就是单写模型两个节点同时挂载同一块镜像盘是绝对禁止的。如果业务需要两个节点同时写入应该选择数据库多副本方案而不是块级镜像。其次它不适合做跨机房容灾。DRBD同步依赖于可靠的局域网连接跨专线的延迟和抖动会让每次写入都变慢而且脑裂风险会急剧上升。跨站点容灾应该走数据库复制或者业务层的多活架构。第三容量扩展不够灵活。所有数据都在两块本地镜像盘上容量被物理盘限制死了。扩容时要么整体迁移数据要么换更大的盘做全量同步。如果需要在线扩容这不是一个友好的选择。那什么场景适合它恰恰是物联网边缘站点这种两台机器、一个房间、数据不能丢、服务要快速恢复、没有专职运维。在这些约束下DRBD Pacemaker 是在“成本”和“可靠性”之间平衡得最好的方案之一。我们运行下来这套系统最爽的一点就是日常维护几乎不需要碰高可用层它安静地待在那里只有真正出故障时才显示价值。前两天某个站点的空调跳闸导致主节点断电手机收到告警我打开电脑时备机已经接管了VIPKaiwuDB的写入链路在几十秒后恢复。那一刻挺感慨的——之前搭这套东西时流的汗算是没白流。
