数据库实时复制：主库挂了，备库怎么做到零丢失？

作者：周靓靓

# 数据库实时复制，不只是“多备一份”那么简单

上个月，一个做电商运营的朋友半夜给我打电话，语气里全是崩溃：“数据库挂了，备份还在，但恢复要两小时，老板说要砍人。”

我问他：“你用的是备份还是复制？”

他愣了一下：“这俩不是一回事吗？”

说实话，这是很多技术人都会踩的坑。备份和复制，听着像亲兄弟，实际差着十万八千里。

备份 vs 复制：一个是“照片”，一个是“直播”

先说个定义句：数据库备份是定期给数据拍张快照，数据库复制是持续把日志流同步到备库。

打个比方。备份就像你每周日给全家拍张合影——万一周三家里被偷了，你只能找回周日那个时间点的样子，中间三天的记忆全丢。复制呢，就像家里装了24小时监控摄像头，每一秒的画面都实时传到云端存储，随时可以回放到任意时间点。

普通备份，RPO（恢复点目标）通常是小时级甚至天级。比如你凌晨2点做全量备份，下午4点系统崩了，那凌晨2点到下午4点这14个小时的数据就没了。我之前遇到一个客户，每天凌晨做一次备份，结果下午3点硬盘坏了，14个小时的订单数据全丢，损失算下来够买三套容灾系统了。

而数据库实时复制，RPO可以做到秒级甚至零丢失。它靠的是持续读取数据库的redo log或binlog，把每一条变更都实时同步到备库。Oracle有DataGuard，MySQL有Group Replication，SQL Server有AlwaysOn，达梦有自己的数据守护（Data Watch），每家都有自己的实时复制方案。

同构复制 vs 异构复制：各有各的命门

先讲同构复制。同构复制就是源库和目标库用同一个数据库品牌，比如Oracle到Oracle，达梦到达梦。

同构复制最大的好处是“省心”。Oracle DataGuard天生就能理解Oracle的redo log格式，传过去直接apply，几乎不用转换。SQL Server的AlwaysOn更是做到了“透明切换”，应用层甚至感觉不到后面发生了主备切换。

我帮一个金融客户做过Oracle DataGuard部署，配置好之后，主库每秒产生几MB的redo日志，备库几乎零延迟。有一次凌晨主库硬件告警，自动切换到备库，业务中断时间不到30秒，客户早上才发现“咦，我们昨晚是不是切换过？”

但同构复制也有坑。最大的坑是——它要求备库和主库的版本、架构高度一致。比如Oracle 19c到11g的DataGuard，基本就玩不转。而且同构复制对网络要求极高，延迟超过几秒，同步就跟不上了。

再说异构复制。异构复制是不同数据库之间做同步，比如Oracle同步到达梦，MySQL同步到SQL Server。

什么场景需要异构？最常见的是信创迁移。很多单位要从Oracle、SQL Server迁移到达梦、人大金仓、OceanBase这些国产数据库。你不能直接停掉老系统，必须让新旧系统并行跑一段时间，这时候就需要异构复制来“搭桥”。

异构复制的问题在于“翻译”。Oracle的redo log和达梦的redo log格式完全不同，需要中间层做日志解析和SQL转换。我之前参与过一个项目，Oracle同步到达梦，踩的坑就是某些Oracle特有的数据类型（比如XMLType、SDO_GEOMETRY）在达梦里没有对应类型，导致同步失败。后来我们不得不在中间件里加了一层“类型映射表”，一个个手工配。

所以我的建议是：能同构就别异构，异构一定要做充分的兼容性测试。

实战场景：源库宕机后，备库怎么“接班”？

讲一个真实案例。

去年一个制造业客户，MES系统跑在SQL Server 2016上，配置了AlwaysOn可用性组，一个主库两个同步提交的备库。

某天下午2点17分，主库所在的存储阵列突然报错，磁盘读写超时。AlwaysOn的健康检测机制在5秒内检测到主库不可用，自动触发故障转移。备库1在2点17分23秒升为主库，业务连接重新定向到新主库。

整个过程业务中断了大约28秒。客户说，操作工还没来得及骂人，系统就好了。

这里有个关键点：自动切换的前提是配置了自动故障转移。很多单位虽然搭了AlwaysOn或DataGuard，但用的是“手动故障转移”模式，意思就是机器挂了还得等人来点那个“切换”按钮。我见过一个医院客户，半夜数据库挂了，值班人员找了半小时才找到DBA的电话，DBA再远程登录切备库，前后花了40分钟。

自动切换的代价是什么呢？“脑裂”风险。如果网络抖动导致主库和备库互相认为对方挂了，两个库都试图成为主库，数据就乱套了。所以一定要配置仲裁机制。SQL Server AlwaysOn有见证服务器，Oracle DataGuard有Fast-Start Failover配合Observer，达梦的数据守护也有类似的监控节点。

信创环境下的数据库复制：达梦+麒麟OS怎么搞？

说到信创，很多朋友头疼。达梦数据库+麒麟操作系统+国产芯片，这套组合在政府、央企、军工系统里越来越普遍。

说实话，达梦的数据守护（Data Watch）功能在核心逻辑上跟Oracle DataGuard很像，也是基于redo日志的主备同步。但有几个坑我必须要说：

第一，达梦的主备切换不完全是“一键式”的。 虽然支持自动切换，但很多单位的内网环境不允许配置自动切换策略（安全合规要求），只能用手动切换。这意味着运维人员必须熟练掌握达梦的“dmwatcher”和“dmmonitor”命令行工具，在故障发生时快速执行切换命令。

第二，达梦和麒麟OS的兼容性问题。 我之前遇到过，达梦8在麒麟V10上跑主备复制，备库apply日志时偶尔会报“内存分配失败”的错误，最后发现是麒麟OS的ulimit参数没调大。这种问题排查起来特别费劲，因为日志里只显示“错误码-8005”，根本看不出是系统问题还是数据库问题。

第三，异构复制在信创环境下的挑战。 如果你要从Oracle迁移到达梦，同时还要保持两套系统并行，推荐用达梦自带的DTS工具或者第三方中间件。但要注意，DTS对Oracle的某些高级特性（比如分区表、物化视图）支持有限，需要手动调整。

选型注意点和常见坑

最后聊聊选型。数据库复制方案这么多，怎么挑？

1. 先看RPO/RTO要求。 金融、医疗行业通常要求RPO=0、RTO<30秒，那你就必须上同步复制+自动故障转移。普通企业如果允许分钟级恢复，异步复制就够了，省钱省力。

2. 网络带宽和延迟是硬指标。 同步复制要求网络延迟低于1毫秒，否则主库性能会大幅下降。我之前一个客户，两个数据中心隔了100公里，网络延迟3毫秒，做同步复制导致主库TPS从5000掉到300，最后改成异步复制才解决问题。

3. 别忘了“反向同步”。 很多单位只做了主到备的复制，没考虑备库升主后怎么把新数据同步回原主库。等原主库修好了，想切回去，发现数据不一致。正确做法是配置双向同步或切换后的反向同步。

4. 测试测试再测试。 我见过太多单位，搭好复制方案就再也不碰了，等真出事了才发现“自动切换没生效”“备库日志应用滞后了半小时”。建议每季度做一次故障演练，模拟主库挂掉、网络中断、磁盘损坏等场景，确保整个流程跑得通。

说实话，数据库复制技术发展到现在，已经很成熟了。但技术成熟不代表落地简单。每个环境都有自己的特殊性，信创环境、异构环境、多云环境，每个因素都可能成为坑。

如果你正在做数据库容灾选型，或者想评估现有方案是否可靠，可以看看热备云的数据保护解决方案，他们在这块积累了不少实战经验，能帮你在复杂环境下找到合适的复制策略。毕竟，数据安全这件事，赌不起。