4、双机冷备架构设计：冷备与热备的区别、数据同步策略、手动切换流程、适用场景分析

各位好，我是老张。在风电行业摸爬滚打了十几年，今天咱们聊聊冷备架构。说实话，冷备这个词儿，很多刚入行的朋友一听就觉得「是不是很low？」其实不然。冷备有冷备的用处，热备有热备的战场。选错了，要么浪费钱，要么关键时刻掉链子。

4.1 冷备与热备：到底差在哪？

先讲个我自己的经历。2016年我在西北某风场做改造，业主坚持要用热备，说「冷备不靠谱」。结果呢？热备系统花了双倍的钱，但现场网络抖动频繁，两台机器来回争主，反而把监控搞崩了。后来我给他们换成了冷备，问题全解决了。

说白了，冷备和热备的核心区别就一句话：备机是否在同步运行。

你想想看，风场监控系统真的需要毫秒级切换吗？大多数情况下，风机数据每5秒上报一次，就算切换花个两三分钟，影响其实不大。但热备带来的脑裂风险、网络依赖、维护成本，却是实实在在的坑。

4.2 数据同步策略：冷备怎么保证数据不丢？

冷备最大的痛点就是数据同步。主机挂了，备机上的数据还是昨天的，那这监控还有什么意义？

我个人的习惯是，冷备场景下采用「定时全量 + 增量日志」的同步策略。具体来说：

• 全量同步：每天凌晨2点，将主机的数据库、配置文件、历史数据完整拷贝到备机。这个操作我建议用 rsync 加压缩，能省不少带宽。
• 增量同步：每15分钟同步一次增量日志。比如风机运行数据、报警记录这些高频变化的内容，只同步变化的部分。
• 关键数据实时写双份：对于「当前风机状态」「最近一条报警」这类关键信息，我建议主机在写入本地数据库的同时，通过一个简单的网络接口写到备机。这样即使主机挂了，备机也能知道最后一刻发生了什么。

嗯，这里要注意一点：增量同步不能太频繁。我曾经见过一个项目，把同步间隔设成了1分钟，结果备机硬盘写坏了——因为每次同步都要创建快照、比对差异，IO压力太大了。

4.3 手动切换流程：一步一步来，别慌

冷备的切换，说白了就是「人肉操作」。但人肉操作最怕什么？怕忘了步骤，怕手忙脚乱。所以我每次做冷备方案，都会把切换流程写成脚本，贴在机柜门上。

下面是我常用的手动切换流程，一共6步：

1. 确认主机故障：先别急着切。检查网络、电源、服务进程，确认不是临时抖动。我一般会等30秒，连续ping三次不通，再确认。
2. 断开主机网络：把主机的网线拔掉，或者关掉交换机端口。这一步是为了防止主机「假死」后突然恢复，导致两台机器同时写数据。
3. 启动备机服务：登录备机，执行启动脚本。脚本里包含了挂载存储、启动数据库、启动监控服务、启动Web界面等操作。
4. 加载最新数据：如果备机上已经有最近一次全量同步的数据，直接加载。如果没有（比如同步周期还没到），就从增量日志里恢复。
5. 验证服务可用：打开浏览器，看看风机状态是不是实时更新的。再随机挑几台风机，手动发个测试指令，看看能不能正常响应。
6. 通知相关人员：在运维群里发个消息，说「已切换至备机，请关注」。同时记录切换时间、原因、操作人。

4.4 适用场景分析：什么时候该用冷备？

说实话，冷备不是万能的。但有些场景，冷备比热备更合适。我总结了三类典型场景：

• 中小型风场（50台风机以下）：监控系统规模小，数据量不大，停机影响有限。花大价钱做热备，性价比太低。冷备完全够用。
• 偏远地区风场：网络不稳定，经常断网。热备的心跳检测在这种环境下会频繁误判，导致频繁切换。冷备反而更稳定——反正平时备机也不在线，不存在争主的问题。
• 预算有限的项目：这个不用多说。冷备可以复用旧服务器，甚至用一台低配工控机当备机。我见过最极端的案例，备机就是一台淘汰的台式机，装了Linux就跑起来了。

但反过来，如果风场是大型基地（200台以上），或者有「无人值守」的要求，那冷备就不太合适了。手动切换需要人到现场，或者至少能远程登录。如果网络断了，人又不在，那冷备就变成了「没备」。

4.5 知识体系总览

下面这张图，是我自己画的冷备架构核心逻辑。你可以把它当成一张「决策地图」，以后做方案时拿出来对照一下。

这张图把冷备的核心要素都串起来了。左边是主机，右边是备机，中间是三种同步策略。下面是人肉切换的5个步骤。最底下是适用场景。你把它存下来，以后做方案时直接套用这个框架，基本不会跑偏。

好了，关于冷备架构，今天就聊到这儿。记住一句话：冷备不是低端方案，而是最务实的冗余选择。下一节咱们聊聊热备的那些坑，到时候再细说。

公众号:蓝海资料掘金营，微信deep3321