随着数字化转型不断深入，各行业的数据体量和并发访问呈现指数级的增长，关键业务对数据中心甚至城市级别的容灾能力提出了更高要求。传统IT系统高可用系统的实现主要是以主备的方式进行部署， 这种方案有着非常广泛的应用和长时间的验证，但仍然无法很好解决例如故障发生后切换数据不丢失的需求，同时由于异步复制机制问题，主中心故障发生后不敢切、不能切的情况时有发生。故障切换的决策成本高，业务影响时间进一步被拉长。
如何面对灾难事件快速完成故障转移，尽可能降低故障爆炸半径，且不丢失数据，从而支撑多种应用系统包括核心系统的管理与使用需求。OceanBase 凭借在支付宝和网商银行多年的真实场景打磨，通过异地部署能力和灵活的副本变换以及负载均衡能力，帮助企业在关键核心场景中进行单元化部署，结合上层调度系统实现任意单元流量在城市和机房间的灵活调拨与切换，沉淀出基于“三地五中心”的数据库异地多活架构，实现单元内故障不影响全局服务的效果，帮助企业在各种关键核心场景中构建金融级多地多活数据库架构。
点击了解 异地多活解决方案的系统架构图及更多信息 》》
相关案例
高德：海量数据多点写入和强一致场景的落地实践
作业帮：多云架构下的数据库集群解决方案，实现资源隔离、快速响应
OceanBase 高可用技术介绍
这一部分会介绍 OceanBase 数据库如何保证高可用，以及一些常见问题。
名词解释
| 名词 | 解释 |
| RTO | 系统发生故障（例如掉电、宕机、进程误杀、系统 Crash、机房故障、灾难等）以后，从故障发生影响数据对外提供服务的时间点，到数据恢复可用，可以对外提供服务的时间点，这两点之间的时间段，叫做服务不可用时间。RTO 即服务恢复时间目标，主要指的是业务能够容忍的最大服务不可用时间。 |
| RPO | 系统在发生故障（例如掉电、宕机、进程误杀、系统 Crash、机房故障、灾难等）后再恢复可用。系统在恢复可用之后的数据与故障发生前的数据差别就是数据丢失量。RPO 即是数据恢复目标，主要指的是业务系统所能容忍的数据丢失量。 |
高可用概述
IT 系统的高可用（High Availability）指的是系统无中断地执行其功能的能力，代表系统的可用性程度。高可用是在系统设计、工程实践、产品能力各个环节上的综合作用，保证业务的持续连续性。而保障系统高可用最重要的焦点就是尽量消除或者冗余单点故障（Single Point of Failure）并且在单点或者系统出现不可用之后提供急速恢复的能力。
故障恢复是指当系统出现短时可恢复故障时，系统恢复可用性、恢复数据服务的一系列过程。灾难恢复是指当机房甚至城市出现灾难或故障事件导致机房或者该城市内机房长时间的故障，不能立即恢复可用时，整个系统恢复可用的一系列过程。企业级应用为了保证业务的连续可用，通常会对系统的可用性有很高的要求，需要保证在故障或者灾难发生时，系统的 RTO 尽量低，RPO 尽量接近 0。
高可用是分布式系统设计中必须考虑的因素，OceanBase 数据库作为一款原生的分布式数据库能够对外提供一致的、高可用的数据服务。OceanBase 数据库的事务一致性，存储持久化保证在出现 OBServer 退出重启情况下能够恢复到重启前相同的数据和状态。另外，OceanBase 数据库的备份恢复、主备库解决方案也保证了在不同场景下 OceanBase 数据库的高可用能力。
OceanBase 用于保证高可用的相关产品能力
OceanBase 数据库分布式选举
解决的故障场景
OceanBase 数据库少数派因为各种原因造成不可用的故障恢复：例如，3 副本 3 台 OBServer 组成的 OceanBase 集群中 1 台 OBServer 宕机、退出；部署在不同机房的少数派副本机房故障；部署在不同城市的少数派副本城市发生灾难。
技术原理
OceanBase 数据库的选举模块保证选举出唯一的主副本对外提供数据服务。同时，通过 Paxos 协议实现了多数派 Clog 强一致同步持久化，在 Paxos 组中任意少数派副本发生故障的情况下，剩下的多数派副本都能保证有最新的 Clog，因此就能避免个别硬件故障带来的数据损失，保证了数据可靠性。当整个 OceanBase 集群中的少数派出现故障时，如果是非 Leader 副本的少数派不可用，不会影响系统的可用性和数据库的性能。如果少数派故障中有 Leader 副本，OceanBase 数据库能够保证从剩余副本选出唯一新主提供数据服务。取决于 OceanBase 集群的搭建部署模式，如果 OBServer 的多个 Zone 分布在不同机房、不同城市时，通过 OceanBase 集群的分布式选举加上 OceanBase Paxos Clog 同步就可以达到跨机房高可用或者是跨城市的高可用方案。 更多信息请参见 OceanBase 数据库选举。
OceanBase Clog 及存储引擎
解决的故障场景
OBServer 多数派故障需要重启；维护计划内的 OBServer 集群重启。
技术原理
OceanBase 数据库的存储引擎将基线数据保存在 SSTable，增量数据保存在 MemTable 中。 OceanBase Clog 是数据的 Redo Log。当有数据修改发生时，请求会到达 Leader 副本所在节点，将数据更改请求更新到 MemTable，事务进行提交，Leader 更新本地 Clog 并通过 Paxos 协议将日志同步写到其他 Follower 的副本节点上。当有多数派节点的日志写盘成功后，数据修改成功，返回客户端。Follower 副本会将 Clog 回放到本地 MemTable 上提供弱一致读服务。
当 MemTable 到达阈值后，会触发冻结和转储，持久到 SSTable 层。而此时的 Clog 回放位点会推进，类似于做了 Checkpoint。在 OBServer 重启时，能够做到从 SSTable 中源数据还原、更新到最新信息。然后，从分区的元信息中获取 Clog 的回放位点，开始回放 Clog 日志生成 MemTable 中。至此，OceanBase 数据库可以将磁盘中的持久化信息恢复到宕机前的状态，保证了数据的完整性。 当 OceanBase 数据库由于故障（软件退出、异常重启、断电、机器故障等）重启或者计划内停机维护重启时，OBServer 能够在启动中恢复，将 OBServer Store 目录下的日志和数据还原到内存中，将进程的状态恢复到宕机前的状态。如果多数派副本故障并需要重启，数据服务会发生中断，OceanBase 数据库保证在多数派宕机重启后数据可以完全恢复到宕机之前。
OBServer 对于多数派宕机重启也进行了进一步的优化处理，加速数据副本恢复加载到 MemTable 的速度，尽快对外提供数据服务。在整个集群重启的情景下，需要将磁盘上最新的 Clog 重新回放到 MemTable 里后对外提供数据服务，在 OceanBase 数据库能够重新恢复数据服务时，数据恢复到集群重启前。
OceanBase 数据库备份恢复
解决的故障场景
OceanBase 数据库出现数据损坏、节点 Crash 或者集群故障，OceanBase 数据库可以从备份的基线数据和 Clog 备份中恢复。
技术原理
当 OceanBase 数据库出现数据损坏、节点 Crash 或者集群故障，OceanBase 数据库可以从备份的基线数据和 Clog 备份中恢复。
OceanBase 数据库主备库
解决的故障场景
机房级的故障或城市级的灾难恢复。
技术原理
OceanBase 数据库也支持传统的主备库架构。 OceanBase 集群的多副本机制可以提供丰富的容灾能力，在机器级、机房级、城市级故障情况下，可以实现自动切换，并且不丢数据，RPO = 0。
OceanBase 数据库的主备库高可用架构是 OceanBase 数据库高可用能力的重要补充。当主集群出现计划内或计划外（多数派副本故障）的不可用情况时，备集群可以接管服务，并且提供无损切换（RPO = 0）和有损切换（RPO > 0）两种容灾能力，最大限度降低服务停机时间。 OceanBase 数据库支持创建、维护、管理和监控一个或多个备集群。备集群是生产库数据的热备份。管理员可以选择将资源密集型的报表操作分配到备集群，以便提高系统的性能和资源利用率。
关于OceanBase 高可用的常见问题
是否支持多机房多地区的部署方式？在部署的时候有哪些基础设施的要求？应该如何选择方案？
在 OceanBase 集群的搭建中，允许将多个副本（节点）分散到多个机房、多个城市中，跨机房/跨城市实现 Paxos Group。在选择多机房、多城市集群架构时，通常也是为了获取机房级容灾甚至是城市级容灾的能力。从技术上来说，只要支撑 OceanBase 数据库不同副本节点的基础设施足够好，在合理的副本分布下，OceanBase 数据库就可以将数据分布在不同的节点上对外提供数据服务。
通常情况下，OceanBase 数据库集群对基础设施的基本要求如下：
- 节点间的网络延迟时间（单向延迟）最好保证在 50ms 以内，最差（单向延迟）也要在 100ms 以内。
- OBServer 环境中的时钟服务应该保证时钟同步的偏差在 100ms 以内，且不能够产生 1s 及以上的时钟跳变。
通常情况下，进行多机房/多城市的的部署方案最重要的是考虑业务和各方面产生的架构需求。因为多机房/多城市的部署方式也会直接带来整个系统成本的大幅提高（例如，跨城市的网络专线部署等）。所以不同的部署方案是一个基于成本、需求、产品能力、方案可行性等多个维度的权衡结果产出。
从技术上来讲，可以解决机房级容灾或者城市级容灾的集群解决方案如下：
- 同城三机房在同城三机房中，三个机房能力对等，都可以承担全部（或者部分）数据的主副本（Leader）角色，同时也承担其他数据的备份副本 (Follower) 的角色。同城三机房集群架构如下图所示。
- 三地五中心五副本城市 1 和城市 2 能力对等，可以承担全部（或者部分）数据的主副本（Leader）角色，同时也承担其他数据的备份副本 (Follower) 的角色，城市 3 仅承担从副本角色。三地五中心五副本集群架构如下图所示。
在实际的部署方案中，OceanBase 团队也根据客户的需求定制过同城双机房和两地三中心的方案。两种部署方案都各自解决了一部分相应场景对于系统高可用的需求，但是同时也存在一定容灾能力的短板。在一定时期有可能作为系统架构的中间态成为客户在初始部署的选择，客户也有可能与 OceanBase 数据库主备库架构搭配使用一起达到期望的容灾能力。具体的方案探讨需要考虑多个因素和方面，如果有实际具体的场景，请联系 OceanBase 数据库技术架构师进行方案讨论和对接。
分布式部署时，如果少数派宕机会发生什么？多快可以恢复？
OceanBase 数据库利用了基于 Paxos 分布式一致性协议保证了在任一时刻只有当多数派副本达成一致时，才能推选一个 Leader, 保证主副本的唯一性来对外提供数据服务。如果正在提供服务的 Leader 副本遇到故障而无法继续提供服务，只要其余的 Follower 副本满足多数派并且达成一致，就可以推选一个新的 Leader 来接管服务，而正在提供服务的 Leader 自己无法满足多数派条件，将自动失去 Leader 的资格。当 Leader 副本出现故障时，Follower 能在多长时间内感知到 Leader 的故障并推选出新的 Leader，这个时间直接决定了 RTO 的大小。
OceanBase 数据库的选举模型是依赖时钟的选举方案， 同个分区的多个全能副本（及日志型副本）在一个选举周期内进行预投票, 投票，计票广播以及结束投票，最终敲定唯一的主副本。当选举成功后，每个副本会签订认定 Leader 的租约（Lease）。在租约过期前，Leader 会不断发起连任，正常情况下能够一直连任成功。如果 Leader 没有连任成功，在租约到期后会周期性的发起无主选举，保证副本的高可用。 在三副本（全能副本）场景下，当一个副本出现异常（例如该节点机器故障，OBServer下线等单点故障），OceanBase 数据库选举模块能够做到：如果原主副本连任成功，原主可以连续提供主副本服务；如果原主副本下线，Leader 连任失败，OceanBase 数据库进行无主选举，新主上任的时间在 30s 内完成。
同时，OceanBase 数据库通过 Paxos 协议实现了多数派 Clog 强一致同步持久化，在 Paxos 组中任意少数派副本发生故障的情况下，剩下的多数派副本都能保证有最新的 Clog，因此就能避免个别硬件故障带来的数据损失，保证了数据可靠性。
分布式选举如何避免脑裂（Split Brain) 问题？
在高可用方案中，一个经典的需要面对的问题就是脑裂问题： 如果两个数据副本因为网络问题互相不知晓对方的状态，并且分别认为各自应当作为主副本提供数据服务，那么这时候就会出现典型的脑裂现象，最后会导致系统混乱，数据损坏。
OceanBase 数据库利用了 Paxos 协议中的多数派共识机制来保证数据的可靠性以及主副本的唯一性：在任一时刻只有多数派副本达成一致时，才能推选一个 Leader。如果正在提供服务的 Leader 副本遇到故障而无法继续提供服务，只要其余的 Follower 副本满足多数派并且达成一致，他们就可以推选一个新的 Leader 来接管服务，而正在提供服务的 Leader 自己无法满足多数派条件，将自动失去 Leader 的资格。
因此，我们可以看到 OceanBase 数据库的分布式选举在高可用方面有明显的优势：从理论基础上就保证了任一时刻至多有一个 Leader，彻底杜绝了脑裂的情况。由于不再担心脑裂，当 Leader 故障而无法提供服务时，Follower 可以自动触发选举来产生新的 Leader 并接管服务，全程无须人工介入。这样一来，不但从根本上解决了脑裂的问题，还可以利用自动重新选举大大缩短 RTO。当然，这里面还有一个很重要的因素，那就是 Leader 出现故障时，Follower 能在多长时间内感知到 Leader 的故障并推选出新的 Leader，这个时间直接决定了 RTO 的大小。
分布式部署时，当多数派故障的时候是否依旧可以服务？
当 OceanBase 数据库中多数派故障，那么对应的分区是无法对外提供数据服务的。为了保证数据的高可用，在整个系统架构设计和运维时，还应当考虑和优化两个副本不相关的连续故障发生的时间。最终保证 MTTF（Mean Time To Failure）应当相较于故障的修复时间 MTTR（Mean Time To Repair）足够的小，以保证整个数据服务的高可用性。当 OceanBase 集群多数派失败的时候，在保留问题分析需要的信息和日志的前提下，应当采取应急措施将集群尽快恢复可用。
副本自动补齐功能是如何工作的？副本自动补齐是否能够保证即使在节点宕机的情况下，相应的分区副本依旧齐全？
当 observer 进程异常终止，若终止时间小于 server_permanent_offline_time，则不作处理，此时有些分区的副本数只有 2 个了（三副本情况下）；当终止时间超过 server_permanent_offline_time时，则对该 Server 做永久下线处理，OceanBase 数据库会在同个 Zone 的其他 Server 开辟区域（资源充裕的 Server），维持副本个数。当有足够的资源时就会发起 Unit 迁移。
