名词解释
名词解释
RTO：系统发生故障（例如掉电、宕机、进程误杀、系统 Crash、机房故障、灾难等）以后，从故障发生影响数据对外提供服务的时间点，到数据恢复可用，可以对外提供服务的时间点，这两点之间的时间段，叫做服务不可用时间。RTO 即服务恢复时间目标，主要指的是业务能够容忍的最大服务不可用时间。
RPO：系统在发生故障（例如掉电、宕机、进程误杀、系统 Crash、机房故障、灾难等）后再恢复可用。系统在恢复可用之后的数据与故障发生前的数据差别就是数据丢失量。RPO 即是数据恢复目标，主要指的是业务系统所能容忍的数据丢失量。
1.什么是系统的高可用？
IT 系统的高可用（High Availability）指的是系统无中断地执行其功能的能力，代表系统的可用性程度。高可用是在系统设计、工程实践、产品能力各个环节上的综合作用，保证业务的持续连续性。而保障系统高可用最重要的焦点就是尽量消除或者冗余单点故障（Single Point of Failure）并且在单点或者系统出现不可用之后提供急速恢复的能力。故障恢复是指当系统出现短时可恢复故障时，系统恢复可用性、恢复数据服务的一系列过程。灾难恢复是指当机房甚至城市出现灾难或故障事件导致机房或者该城市内机房长时间的故障，不能立即恢复可用时，整个系统恢复可用的一系列过程。企业级应用为了保证业务的连续可用，通常会对系统的可用性有很高的要求，需要保证在故障或者灾难发生时，系统的 RTO 尽量低，RPO 尽量接近 0。高可用是分布式系统设计中必须考虑的因素，OceanBase 数据库作为一款原生的分布式数据库能够对外提供一致的、高可用的数据服务。OceanBase 数据库的事务一致性，存储持久化保证在出现 OBServer 退出重启情况下能够恢复到重启前相同的数据和状态。另外，OceanBase 数据库的备份恢复、主备库解决方案也保证了在不同场景下 OceanBase 数据库的高可用能力。
2.OceanBase 数据库有哪些产品能力保证了数据服务的高可用？
（1）
**产品能力及解决方案： **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 数据库选举。
（2）
**产品能力及解决方案：**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 数据库能够重新恢复数据服务时，数据恢复到集群重启前。
（3）
**产品能力及解决方案：**OceanBase 数据库备份恢复
**保证的故障场景：**OceanBase 数据库出现数据损坏、节点 Crash 或者集群故障，OceanBase 数据库可以从备份的基线数据和 Clog 备份中恢复
**工作原理：**当 OceanBase 数据库出现数据损坏、节点 Crash 或者集群故障，OceanBase 数据库可以从备份的基线数据和 Clog 备份中恢复。
（4）
**产品能力及解决方案：**OceanBase 数据库主备库解决方案
**保证的故障场景：**机房级的故障或城市级的灾难恢复
**工作原理：**OceanBase 数据库也支持传统的主备库架构。 OceanBase 集群的多副本机制可以提供丰富的容灾能力，在机器级、机房级、城市级故障情况下，可以实现自动切换，并且不丢数据，RPO = 0。
OceanBase 数据库的主备库高可用架构是 OceanBase 数据库高可用能力的重要补充。当主集群出现计划内或计划外（多数派副本故障）的不可用情况时，备集群可以接管服务，并且提供无损切换（RPO = 0）和有损切换（RPO > 0）两种容灾能力，最大限度降低服务停机时间。
OceanBase 数据库支持创建、维护、管理和监控一个或多个备集群。备集群是生产库数据的热备份。管理员可以选择将资源密集型的报表操作分配到备集群，以便提高系统的性能和资源利用率。