远程复制：企业灾备避坑指南

作者：陈景行

上周五晚上十一点，我正在洗澡，手机在客厅疯狂震动。擦干手一看，是值班同事打来的。他说核心业务库的存储控制器挂了，整个存储阵列处于只读状态，新写入的数据全被卡住。

我第一反应是：备份呢？

他说备份系统倒是正常，但最近一次完整备份是昨晚两点，意味着当天白天的数据全得丢。电话那头沉默了几秒，然后他问了一句让我至今都记得的话：“要是当初把数据实时扔到另一台机器上，是不是就不用这么慌了？”

他说的，就是今天要聊的远程复制。不是什么高深莫测的东西，说白了就是一份数据同时写两份，一份留在本地，一份通过网络写到远处的另一台存储或者服务器上。本地那份挂了，远处的还能接着用。

远程复制到底解决什么问题？

先给个定义，免得大家看迷糊。远程复制，也叫远程镜像或异地复制，是把生产存储上的数据通过同步或异步方式，复制到远端设备上。它跟备份最大的区别在于——备份是定期做快照，有恢复点目标，可能丢几小时甚至一天的数据；远程复制是持续性的，数据几乎实时到达远端，恢复点目标基本为零。

我之前有个客户，做电商的，促销日峰值每秒上千笔订单。他们做过一次演练，用备份恢复，花了两小时四十分钟，把当天凌晨两点之后的所有订单全部回滚。财务部门差点疯了，因为账对不上。后来他们上了远程复制，再演练，切到灾备端只用了十一分钟，数据一条没丢。

这就是远程复制解决的问题——当“丢几小时数据”变成“丢几百笔订单”的时候，备份就不够用了。远程复制要的是那种“就算本地机房烧了，远端数据还是完整的”的底气。

同步和异步，别选错了

远程复制分两种模式，同步和异步。说实话，很多刚接触的人容易在这上面踩坑。

同步复制，是本地写完，必须等远端也写成功，才给应用返回成功。数据绝对一致，但网络延迟会直接影响业务写入性能。你想想，本地写操作本来一毫秒就返回，现在要等数据跑到几十公里外再回来，可能变成五毫秒甚至十毫秒。对延迟敏感的业务，这是致命的。

异步复制，是本地写完就返回，数据在后台往远端传。业务性能不受影响，但极端情况下可能丢几秒甚至几十秒的数据。比如租用的专线突然断了，还没来得及传过去的数据就丢了。

我遇到过最典型的坑是——一个客户选了同步复制，结果生产端和灾备端距离八十公里，网络延迟三毫秒，业务系统写入性能直接掉了百分之四十。数据库监控告警刷了一屏，开发团队以为是代码问题，查了两天，最后发现是复制模式选错了。

所以我的建议是：对一致性要求极高、网络延迟低于两毫秒的场景，选同步；其他情况，老老实实用异步。别为了“绝对不丢”的执念，把生产性能拖垮了，得不偿失。

带宽和延迟，比你想象的更关键

远程复制本质上是网络技术。很多人以为只要买了足够大的带宽就行，其实不然。

远程复制的带宽需求，不是按数据总量算的，而是按“变化量”算的。你可能有十T的数据，但每天真正变化和新增的可能就几百G。远程复制要传的是这几百G，不是那十T。所以评估带宽，得看业务峰值时段的写入速率，而不是存储总容量。

之前有个客户，业务量不大，但喜欢搞促销活动，每次促销那两小时，数据库写入量是平时的十倍。他们按平均写入量买了带宽，结果促销一开始，复制队列越积越长，远端数据落后了四十多分钟。等发现的时候，勉强能接受，但已经失去了“实时”的意义。

还有个容易被忽略的点是延迟。带宽再大，距离远了延迟也高。异步复制对延迟没那么敏感，但同步复制就完全依赖延迟。之前那客户选同步模式后性能暴跌，就是因为忽略了延迟这个参数。

避坑提醒：如果条件允许，优先选同城或同区域的两个机房做远程复制，延迟低，带宽成本也低。跨地域的复制，建议用异步模式，并且要接受那几秒的数据丢失窗口。

别忘了做切换演练

远程复制系统搭好，不代表就万事大吉了。说实话，很多人搭完之后就再也不管，等到真出事才发现各种问题。

我见过最夸张的一次——某单位做灾备切换演练，远程复制数据倒是完整，但灾备端的服务器配置和生产端差了整整一代，数据库版本也不一样。切换过去之后，业务系统起不来，折腾了三个多小时才勉强恢复。演练报告写得很难看，但至少发现了问题，比真出事那天才发现强。

所以我的建议很简单：每季度至少做一次完整的切换演练，别只验证数据是否能读到，要把业务系统整个切过去跑一天。只有真正把应用在灾备端跑起来，你才知道那些中间件配置、网络策略、DNS解析是不是都准备好了。

这个坑我自己也踩过。之前帮一个客户做切换测试，数据复制完全正常，但切换过去之后，应用服务器连不上数据库——因为安全组规则没放行灾备端的IP段。就这么一个小问题，让整个演练推迟了整整一天。后来我们改了流程，每次演练前先检查网络策略，再验证数据，再切业务。

说点实在的

远程复制不是什么新鲜技术，但很多企业要么没用，要么用了没用好。问题往往不出在技术本身，而是出在规划和运维上。

我见过一些企业，远程复制用是用了，但复制链路从来没监控过，复制积压了多少数据都不知道。也见过一些企业，复制目标端容量规划不足，跑了一年才发现远端存储快满了，复制任务静默失败了两周。

之前有段时间，我用中科热备的远程复制功能帮一个客户做过异地容灾，效果还不错。但说实话，工具只是工具，关键还是得有人懂原理、会运维。

如果你现在正在考虑上远程复制，我的建议是：先梳理业务的重要程度，分清哪些系统需要同步复制，哪些异步就够；再评估网络条件，别盲目追求零丢失；最后，一定要做切换演练，至少每季度一次。

数据保护这件事，平时看着像花钱买心安，真出事的时候才知道它值多少钱。远程复制不是银弹，但它能让你在灾难面前，多一条退路。