世界领先！一文详解OceanBase的高可用及容灾方案

小蚂蚁说：本文是“OceanBase高可用及容灾方案”系列文章的上篇，本文将带你一起总结和回顾传统数据库产品常用的高可用及容灾方案。后面的两天将为你带来本系列的中篇和下篇，将为你深度解读基于OceanBase最佳实践的分布式数据库的高可用及容灾方案。欢迎关注“OceanBase”微信公众号，持续关注本系列文章！

本文作者：萧石

本文作者：鸷腾

现任蚂蚁金服OceanBase高级技术支持专家。曾经在亚信、IBM、巨杉数据库等公司有多年的数据库使用及技术支持经验，现在蚂蚁金服负责OceanBase数据库的外部客户推广技术支持工作。

前言

众所周知，作为生产系统中极为关键的核心软件，数据库产品的高可用性一直是使用者极为关注的功能点。尤其是在金融这样一个特殊的领域里，无论是从监管的要求来看，还是从业务需求本身来看，都需要提供24*7持续不间断的服务，这就对金融行业中数据库产品的高可用性提出了很高的要求。不但需要应对个别硬件故障的情况，还必须能够应对机房整体故障和城市灾难等极端情况，保证数据库在各种意外情况下都能持续提供服务，即具备机房级容灾能力和城市级容灾能力。

本文的主要目的，是总结和回顾一下传统数据库产品常用的高可用及容灾方案，并向读者介绍一下以OceanBase为代表的分布式数据库常用的方案，希望能够起到抛砖引玉的作用，引发读者关于新型分布式架构下高可用及容灾方案的思考。

传统商业数据库高可用方案

首先，我们回顾一下传统的关系型数据库产品（如Oracle、DB2等）常用的高可用及容灾技术。我们知道，传统数据库产品最初都是单点架构，并不具备高可用设计，更多的是基于高端硬件产品满足“硬件可靠”的假设。

随着时间的推移，传统数据库产品先后推出了采用“主从复制”架构的高可用方案，比如Oracle的Data Guard技术和DB2的HADR技术，其主要思路是：在原有的单数据库节点（主节点）之外再增加一个对等的数据库节点（从节点），通过数据库层面的复制技术（通常是日志复制）将主节点产生的数据实时复制到从节点；正常情况下从节点不提供对外服务，当主节点发生故障时，在从节点上执行“切主”动作将从节点变成主节点，继续提供服务。在主从节点的部署方式上，除了本地单机房部署外，往往也支持同城灾备部署和异地灾备部署，因此也就具备了机房级容灾和城市级容灾的能力。很多新兴的数据库产品（如MySQL）也是采用“主从复制”模式来实现高可用及容灾特性。

除了数据库层面的主从复制技术之外，还有一些在底层硬件上实现的高可用方案，比如在主机层面用HACMP技术以应对主机故障，或者在存储层面采取复制技术（比如FlashCopy）来提供数据冗余等。这些技术虽然也可以用来实现高可用和容灾能力，但和应用的整合度不高，会使灾难切换方案变得很复杂，并且会有相对较长的故障恢复时间（RTO），所以通常不是数据库用户的首选。

最后，近些年还出现了一些支持异种数据库之间相互复制数据的产品，比如IBM CDC和Oracle Golden Gate（OGG）。这些产品的特点是比较灵活，可以支持异种数据库之间的数据复制，也可以指定只复制数据库中的部分对象（比如只复制指定几张数据表的数据）。但这些产品的缺点也很明显：首先相对于数据库主从复制来说时延偏大，通常会达到秒级以上，而且往往做不到数据库层面100%的完全复制。

因此，这种方式通常作为不同数据库产品之间做数据“准”实时同步的手段，而不会作为数据库产品实现高可用及容灾的手段。

稍微总结一下，传统的数据库产品通常会采用下面的方法实现高可用：

在主机层面实施高可用（HACMP）架构，以应对主机故障所带来的影响（非首选方案）

在存储层面采用数据复制技术（比如FlashCopy）来提供数据冗余，以应对存储损坏所带来的影响（非首选方案）

在数据库层面提供“主从复制”技术（首选方案）

第三方数据复制产品，如CDC、OGG等（很少采用）

通过上述的各种技术，尤其是数据库“主从复制”技术，使得意外发生时数据库可以在一定时间内恢复服务，并且大部分数据不会丢失，具备了一定的高可用及容灾能力。但是，上面这些技术也有一些难以克服的缺点，以“主从复制”技术为例，虽然它是传统数据库里最先进也是最常用的高可用及容灾技术，但还是有一些无法解决的问题：

通常情况下无法做到RPO=0，即主节点发生故障或者灾难时有交易数据的损失。

可能有的读者会说：你说错了！主从复制技术也能实现RPO=0！

是的，理论上讲主从复制技术是可以利用强同步模式（比如OracleData Guard中采用Max Protection模式，或者DB2 HADR中采用Sync模式）做到RPO=0，但实际应用中，像银行核心系统这样的关键业务里却不会采用。

为什么呢？因为这种模式将主节点和从节点以及主从节点之间的网络环境紧紧地绑在了一起，主节点的稳定性将不再由它自己决定，而要同时看从节点和网络环境的脸色：一旦从节点或者网络环境稍微抖动一下，主节点的性能就会受到直接影响。如果主节点和从节点之间是跨机房甚至跨城市部署，发生这种问题的概率会更大，影响也会变得更加显著。

从某种程度上讲，和单节点模式相比，这种模式下主节点的稳定性不但没有增加，反而是降低了。如果有银行的朋友在关键业务中应用过Oracle Data Guard或者DB2 HADR，对强同步模式所带来的问题应该是深有体会的。

RTO相对较大，通常以十分钟甚至小时为计算单位，会给业务带来比较大的损失。

造成这一情况的根本原因，是“主从复制”模式下从节点不具备自动切主的能力。

由于“主从复制“模式中缺少第三方仲裁者的角色，当主从节点之间的心跳信号异常时，从节点无法靠自己判断到底是主点故障了，还是主从之间的网络故障了。此时，如果从节点认为是主节点故障而将自己自动切换成主节点，就极容易导致“双主”、“脑裂”（brain-split）的局面，对用户来说这是绝对无法接受的结果。所以数据库“主从复制”技术从来不会提供“从节点自动切换为主节点”的功能，一定要由“人”来确认主节点确实故障了，并手工发起从节点的切主动作，这就大大增加了系统恢复的时间（RTO）。

聊完了传统数据库的高可用技术，我们再来看看另一种逐渐被越来越多的技术厂商所采用的技术，那就是分布式多副本数据一致性技术，通常是基于Paxos协议或者Raft协议来实现。这种技术会将数据保存在多份副本上，每一次对数据的修改操作都会强同步到多数派副本上，在保证了数据冗余的同时，不再像“主从复制”技术那样依赖某个数据节点的稳定性，从而消除了传统主从复制技术下从节点给主节点带来的风险。

同时，在主节点故障的情况下，其余节点会自动选举出新的主节点以实现高可用（个别从节点故障则完全不影响服务），整个过程非常快速且完全无需人工干预。因此，这种技术不仅能保证RPO=0，而且大大减小了RTO，相比传统“主从复制”技术来说可以提供更强大的高可用能力。

此外，为了抵御机房级灾难和城市级灾难，可以将多份副本分散部署在多个机房里甚至多个城市中，以避免机房级灾难或者城市级灾难损毁多数派副本。这样就具备了机房级容灾和城市级容灾的能力，进一步加强了高可用的能力。

下期预告

本文是《OceanBase的高可用及容灾方案》系列文章的上篇，后面两天我们会为大家带来该系列的中篇和下篇。

在中篇里我们会针对性地与大家探讨基于OceanBase最佳实践的七大高可用及容灾解决方案。在下篇我们还会系统性的分析这些高可用及容灾解决方案的特点和适用场景。欢迎关注“OceanBase”公众号，持续关注本系列文章！

OceanBaseTechTalk · 杭州站

今日份荐文