基于多副本的高可用解决方案

基于 Paxos 一致性协议的多副本高可用解决方案

该方案基于Paxos一致性协议实现，通常在同一个集群内通过多副本（例如，三副本或五副本）提供容灾能力。

在少数派副本不可用（三副本集群允许一个副本不可用，五副本集群允许两个副本不可用）时，数据库可以自动执行容灾切换并恢复服务，保证不丢数据（RPO = 0），故障恢复时间在 8 秒以内（RTO < 8s）。

用户可以通过灵活调整集群各个 Zone 的机房和 Region 分布，以及租户副本在这些 Zone 上的分布，从而调整租户的部署模式，达到不同的容灾级别。

OceanBase 数据库支持的容灾等级如下所示。

部署模式	最佳副本数	容灾场景	容灾能力
单机房	三副本	面向不具备多机房条件的场景。同机房内三副本组成一个集群，同一份副本尽量部署在相同容灾能力的一组机器上，例如：同一个机架、同一个电源等。	能够防范少数派节点故障。无法防范机房级故障（例如，机房网络中断、电力中断等）、城市级故障（例如，地震、海啸、台风等自然灾害等）。
同城三中心	三副本	面向具备一个城市三个机房的场景。同城三个机房组成一个集群（每个机房是一个 Zone），机房间网络延迟一般在 0.5 ~ 2 ms 之间。	能够防范少数派节点故障。能够防范单机房故障。无法防范城市级故障。
两地三中心	五副本	面向一个城市只具备两个机房的场景。主城市与备城市组成一个 5 副本的集群，主城市 4 副本分布于两个 IDC，备城市 1 副本。任何 IDC 的故障，最多损失 2 份副本，剩余的 3 份副本依然满足多数派。	能够防范少数派节点故障。能够防范单机房故障。无法防范主城市的故障。
三地五中心	五副本	面向需要城市级容灾能力的场景。三个城市，组成一个 5 副本的集群。两个城市各 2 份副本，第三个城市 1 份副本。任何一个机房或者城市的故障，依然构成多数派，可以确保 RPO=0。	能够防范少数派节点故障。能够防范少数派机房故障。能够防范少数派城市故障。

三种部署模式示意图如下所示：

• 同城三中心部署模式

  

• 两地三中心部署模式

  

• 三地五中心部署模式

  

OceanBase 数据库的部署模式通过租户级别的 Locality 属性来描述，我们在《副本管理》章节中描述了三种部署模式的 Locality 示例，通过调整租户的 Locality 属性，从而达到灵活的部署模式，进而达到不同的容灾级别。详细信息参见 Locality 介绍。

多副本技术的容灾架构，其核心逻辑是通过 Paxos 协议保证事务日志达成多数派提交。如果发生故障的节点小于多半数，选举协议能够保证自动恢复，且 RPO = 0。如果多于半数的节点发生故障，就需要人工介入，可以通过单副本的方式拉起服务，由于少数派可能没有包含最新的数据，因此可能会丢失最后一部分数据。

注意

单副本拉起操作不是常规的运维操作，是集群无法恢复时最后的应急手段，有数据丢失和双主的风险，操作需要特别谨慎，请在 OceanBase 支持同学指导下进行，本文档暂不提供操作细节。

在金融行业里，传统关系型数据库往往也部署成“两地三中心”架构，同城两个机房，一个主库，一个热备，异地一个冷备。虽然可以通过数据库原生的半同步机制来保证业务更新的同时也提交到备库，但并不是强保证机制，当主库出现故障时，备库依然可能没有最新的更新，并且强制将备库切为主库可能会导致数据丢失。这就意味着，传统关系型数据库的“两地三中心”架构要么选择高可用，要么选择强一致，无法打破 “CAP 理论”。但 OceanBase 数据库基于 Paxos 协议的多副本容灾技术真正做到了同城和异地的无损容灾，达到 RPO = 0，RTO < 8 秒。

通过 OceanBase 数据库的多副本技术实现的容灾架构，应用只需要感知一个数据源，数据库内部复制的细节对应用完全透明。同时，它提供了单机级、机房级、甚至城市级故障的无损容灾能力，并且恢复时间小于 8 秒。

单机容灾

OceanBase 数据库内部的心跳机制能够自动处理节点异常，OBProxy 也能够感知节点异常状态，从而避免应用层对节点异常状态的感知。为了避免节点的非通断型故障引起的乒乓效应持续短暂影响应用，应该第一时间隔离异常节点，隔离异常节点的相关操作可参见 隔离节点；如果隔离节点后自动产生的 Leader 不是最优，您可以通过主动切主的方式将 Primary Zone 切到指定 Zone，主动切主的详细操作请参见 数据库层高可用。

对于故障节点的后续处理，分为以下两种场景：

• 故障 OBServer 可以重新启动

  不论故障机器之前处于何种心跳状态，OBServer 重新启动后，OBServer 与 Root Service 之间的心跳数据包恢复以后，OBServer 可重新提供服务。重启 OBServer 的详细操作请参见 重启节点。

• 故障 OBServer 损坏，无法重新启动

  在确认 OBServer 损坏无法重新启动后，需要走机器替换流程，即下线故障节点，并重新上线新机器。有关替换机器的详细操作请参见 替换节点。

机房容灾

机房级容灾要求集群部署满足多机房部署条件，例如，同城三中心和两地三中心。该部署模式下，任何机房故障导致少数派副本不可用时，剩下的多数派副本依然可以继续提供服务，保证零数据丢失。如果机房故障仅影响到单个 Zone，您可以通过 Stop Zone 的方式隔离故障副本，通过 Stop Zone 隔离故障 Zone 的相关操作请参见 隔离 Zone；如果机房故障影响到多个 Zone，您可以通过主动切主的方式将 Leader 切换到指定 Zone，主动切主的详细操作请参见 数据库层高可用。

城市容灾

城市级容灾要求集群部署满足多城市部署条件，例如，三地五中心。该部署模式下，任意一个城市故障，最多损失两个副本，剩下的多数派副本依然可以继续提供服务，保证零数据丢失。如果自动选举产生的 Leader 不是最优，或者为了避免城市级故障的间隙性影响，您可以通过切主的方式将 Leader 切换到最优 Zone。