架构类型 

        Oracle、MySQL、SQLServer等主流数据库，都拥有其原生容灾架构，如Oracle Dataguard、Oracle RAC、MySQL主从/多主、Failover Cluster、AlwaysOn、MySQL NDB cluster，以及各种第三方容灾架构：GoldenGate、 MHA、MMM、PXC/Galera等等。

        面对眼花缭乱的各种架构，首先需要明确的是，架构实现容灾的底层逻辑，不外乎三类：

• 日志同步架构

        日志同步，顾名思义，是借助数据库日志，让主库将所有数据操作均“抄写”给远端的备库，从而实现备库与主库之间数据同步的容灾架构。

        日志同步是最泛用的容灾同步方式：

        原生架构中，Oracle的DG/ADG、MySQL的主从/多主架构、SqlServer的Alwayson架构均为日志同步；而第三方产品或架构中，GoldenGate、DSG、Shareplex、MMM、MHA等也都是日志同步。

        由于只需要传输日志，日志同步架构非常经济实惠：它没有额外的设备需求，只需要网络可达即可部署，因此架构成本较低。同时，在没有强一致性需求时，日志同步架构对主库的性能影响也比较小。鉴于上述优势，日志同步架构自然成了DBA最常用的数据库容灾架构。

        然而，除非开启了“强一致性”，如Oracle DG的最大保护模式，否则日志同步并不是真的同步复制，而是“异步”或“半异步”复制，一旦主库发生故障，日志同步架构并不能保障最新的数据不丢失。

• 存储共享架构（Share Disk）

        存储共享架构，即多个计算节点共享一套存储，借助存储设备自身的容灾能力，实现本地容灾的架构。许多HA（高可用）架构都是存储共享类型的，其中最为典型的例子就是Oracle RAC。

        存储共享架构天然就是数据强一致性的，并且作为高可用架构，存储共享架构的读写性能基本没有损失甚至比单节点更好。因此，即使该架构实现成本比较高，DBA仍然倾向于使用该架构架设数据库。

        然而，受限于存储共享的物理限制，该架构基本只能本地部署。在面对站点级故障的风险时，只能靠叠加其他容灾架构防范：如Oracle RAC加远端DG备库。此时又将面临日志同步架构带来的一系列隐患。

• 分布式架构（Share Nothing）

        分布式架构，互联网时代数据库架构的新宠，成本较存储共享架构更低，且部署灵活。典型的分布式架构如MySQL的PXC、Galera、NDB Cluster、PostgreSQL的Greenplum以及Citus等。

        分布式架构根据数据冗余方式又分为全量冗余和数据段分布两种。全量冗余即所有计算节点均保留全量数据副本，无需其他节点参与即可完成所有工作，典型的如MySQL PXC。数据段分布则使用hash分布等方式将数据分段存放在不同节点中，每个数据段节点再进行mirror，实现分组数据冗余，典型的如PostgreSQL Greenplum。

        从灾备角度来看，分布式架构似乎完全可以跨站点部署节点，实现跨站点灾备。但在实际使用中，全量冗余型架构写性能和DDL均有较大性能瓶颈，数据段分布型架构则在做连接查询时涉及数据跨节点分布的问题。这两点作为分布式架构的通病，会在跨站点部署中被放大，造成严重的性能问题。

        即使不考虑容灾，分布式架构的性能瓶颈问题仍决定了该架构并非通用架构，而是旨在解决高并发读或高并发写环境下数据库的IO瓶颈问题（全量冗余优势在读IO，数据段分布优势在单表读写）。

主流容灾架构的局限性

        在了解了数据库主流的容灾架构类型后，结合数据库故障场景，我们不难发现以下几个问题：

• 数据库容灾架构无法解决逻辑故障

        从一个小小的误操作（DML），到疑似删库跑路（DDL），无论发生什么规模的逻辑故障，都足以让DBA心中一凉——以数据一致性作为容灾目标的数据库架构，并不存在智能检查数据误操作、保存正确数据版本的能力。因此DBA只能顶着巨大的压力，在闪回查询、闪回数据库、日志flashback等手段上挨个尝试，条件实在不满足时，甚至只能动用最后的手段——调备份恢复……

• 数据库容灾架构在跨站点容灾方面存在短板

        理论上来讲，日志同步和分布式架构都可以跨站点部署，直接实现跨站点复制的能力。然而跨站点意味着远距，窄带，也就意味着传输质量不稳定，漫说真的遇到站点故障时灾备端数据一致性是否有保障，就是日常处理的各种传输异常告警，以及偶有发生的重建远端站点失联备库的需求，就够DBA喝一壶的。

• 数据库容灾架构本身也会出现故障，修复架构故障会成为额外工作

        使用DataGuard保护主库，结果主库三四年没出一次故障，倒是DG备库发生了好几次故障，多次需要重建与主库的同步关系——这样的情况，在DBA看来并不陌生。虽说不太直接影响生产，但也带来了更多工作量，尤其是熬夜量。

针对上述问题的新思路 

• 逻辑故障

        即使SQL审核再严格，数据误操作都无法完全杜绝。DBA面对逻辑故障时一定先祈祷误操作发生的时间点在闪回查询可追述时间范围中，否则找回数据就意味着需要停数据库甚至调用备份，这往往意味着巨大的时间开销。

        譬如，当一个误删改发生在15分钟内，DBA当然可以轻松地使用闪回查询找到数据被删改之前的正确版本，并将其在线还原。然而，当误删改操作发生在半天前，甚至数天前，直到现在才被发现；又或者误删改操作后，数据对象发生了DDL操作；再或者这个误操作本身就是DDL操作时——DBA也只能先下单今晚的夜宵了……

        当DBA们奋战到后半夜，只为了调用备份（或者先备份再闪回数据库）得到正确的数据版本修复某位同事的误操作时，脑中一定会设想，如果有一个工具，可以超越undo的限制，长时间连续记录下整个数据库的状态，还能轻易恢复出一份任意时间点的数据，那么DBA们就等于拥有了一个有超长追述能力的闪回查询神器，从此不再需要为逻辑故障加班。

        今天的DBA将有机会梦想成真！——新一代的True CDP产品CloudWonder SVS。

        作为一款真正能够实现IO级别CDP（Continuous Data Protection持续数据保护）的产品，SVS可以在极高IO压力下复制并保护整个数据库的所有IO变化，并对所有IO信息实现分析可视化。DBA可以选择任意时间点或IO节点，对被保护的数据库磁盘创建一份或同时创建多份完全相同的数据镜像，无需占用磁盘空间。无论该数据盘容量多大，这个创建速度都是秒级的，即使加上镜像盘挂载和启动数据库实例的时间，DBA也基本上可以在10分钟之内就通过这个方式获取到想要的数据副本——速度远超需要停库的闪回数据库操作，更不用提使用传统备份恢复。

        作为新一代的True CDP产品，SVS使用在线存储块级别的全局数据重删的机制，任意副本的创建只会占用指针，这不仅实现了秒级历史版本克隆，还消除了过往CDP产品对存储性能与空间的巨大消耗，同时还引入了CDM等数据再生的理念，可随时随地提供DBA所需的数据库真实副本。

        也就是说，DBA借助SVS，就可以拥有一个跨越任意DDL操作、超长追述时间、且回溯效率差不多媲美闪回查询的能力。这一切甚至没有副作用——不会对主库性能造成任何影响。

• 站点容灾

        相对逻辑故障，站点级故障发生的概率虽小，一旦造成的灾难却不容忽视。应对站点级故障的容灾，数据库现有的容灾架构都不是最理想的解决方案：

        日志同步架构也好，分布式架构也罢，都面临数据一致性和性能无法兼得的问题，需要保障一致性时，本地事务和DDL操作都需要等待远端站点的灾备端完成后才能继续进行，势必极大影响数据库性能；而需要保障性能时，则无法保证灾备端的数据一致性，甚至当传输链路过于复杂时，还会出现由于种种原因导致灾备断档，需要重做全量复制的情况。更不用提站点级容灾做容灾演练时，容灾架构节点的读写角色切换并不是毫无代价的。

        因此，DBA们从一开始就不太愿意考虑跨站点部署数据库容灾架构。

        传统上来说，需要达到站点容灾能力的企业，宁可选择使用高级存储设备的远端快照能力实现数据库跨站点容灾。然而这个方案不但昂贵，还需要同构存储设备才能实现，而且也无法达到真正的连续保护——故障发生时，最多只能恢复到最新的快照。

        如今这个方案已经可以完全被更加物美价廉的SVS所替代：

        SVS可以兼容几乎任意品牌和型号的存储设备，可以利用第三方存储作为数据保护的存储介质，并将IO变化信息同步到远端站点的任意存储设备中。

        与存储复制类似，由于IO变化信息较日志信息占用带宽更小，且一致性校验不会直接影响主库性能，SVS的传输可靠性自然远超日志同步方式。

        DBA获得的并不是一份份不连续的数据快照，而是基于CDP技术的数据“录像”。就如在“逻辑故障”章节中介绍的那样，这份录像可以在任意时间点上产生数据副本进行数据库恢复，当然也包括与主库完全一致的最新状态。至于对主库的性能影响：几乎为0。

        谁说鱼与熊掌不可得兼？

• 架构性故障

        也许对许多企业而言，跨站点容灾遥不可及，逻辑故障靠加强流程审核规避，似乎依靠数据库容灾架构，也就基本够用了。

        然而，系统架构上有一个基本逻辑：架构上每加一种角色，本身就会带来新的风险。

        数据库容灾架构也是如此，容灾架构本身也会出现故障：例如日志同步架构中由于网络或文件故障导致日志断档；存储共享架构中由于网络或仲裁出错导致的脑裂故障；分布式架构中管理节点出错，计算节点脱离等情况……

        此时，DBA除了需要排除故障外，还常常需要修复故障节点的数据——这一般意味着需要使用全量备份进行恢复，或者使用健康节点向新节点重传全量数据。这意味着大量的时间和性能花销。

        譬如最常见的Oracle DG的LOG GAP问题，当备库由于日志断档出现无法与主库同步时，要么需要协调主库备份时间窗口，做一个从断档SCN号开始的RMAN增量备份进行备库恢复；要么只能调度常规完整全量备份集进行备库恢复。无论使用哪种方式，DBA需要协调的资源和花费的时间精力都不小：

        一般来说，DBA首选使用增量备份修复DG备库。但出于不能影响主库性能的考虑，增量备份操作窗口只能选在后半夜——于是DBA掏出手机，熟练地下单了今晚的夜宵……

        由于数据库每日数据量变化非常大，整个后半夜已经被每日增量备份作业填满，估计没法插入另一个增量备份操作。无奈之下，DBA退而求其次，选择调用主库完整的全量和增量备份进行备库恢复。备份调度花了三个小时，备份恢复从中午十二点正式开始，预计需要花费十四个小时——夜宵倒也不用退。

        相信做过DBA的朋友，都能从手机上的外卖订单中，准确找到每份夜宵对应的守夜作业。

        如今，我们有了一个更加便捷的产品：NaviClouDR。

        作为一款块级别灾备产品，NaviClouDR可以毫无阻碍地对正在运行的数据库主库或从库拍摄快照，最极致的情况下，可以提供每分钟一个快照的连续保护模式。更重要的是，NaviClouDR可以实现与各类公有云、私有云平台的自动化对接，如阿里云、腾讯云、天翼云、Azure、AWS、GCP等等，能够为DBA在本地私云环境以及公有云环境随时提供数据库的第二平台服务，应对数据库日常运维过程中对真实副本的操作需求，不仅仅用于保护与救灾。比如测试，验证，分析等等场景。放在过去，要实现以上能力，用户需要采购昂贵的服务器以及存储设备予以支持，且准备周期漫长，效率低下。

        NaviClouDR还提供恢复过程中的前置和后置脚本功能，仅需一次简单的定制化配置，从此容灾节点的新增或数据恢复都可以一键实现。

        从此也省了不少夜宵钱。