--- title: "高可用 FAQ - OceanBase 数据库 V4.3.4 | OceanBase 文档中心" description: 高可用 FAQ 什么是系统的高可用？ IT 系统的高可用（High Availability）指的是系统无中断地执行其功能的能力，代表系统的可用性程度。高可用是在系统设计、工程实践、产品能力各个环节上的综合作用，保证业务的持续连续性。而保障系统高可用最重要的焦点就是尽量消除或者冗余单点故障（Single Point … --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 4.3.4 # 高可用 FAQ 更新时间：2025-03-25 14:31:57 [编辑](https://github.com/oceanbase/oceanbase-doc/edit/V4.3.4/zh-CN/800.FAQ/700.high-availability-faq.md) ## 什么是系统的高可用？ 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 合在一起后，保证有完整的 Clog，因此就能避免个别硬件故障带来的数据损失，保证了数据可靠性。 当整个 OceanBase 集群中的少数派出现故障时，如果是非 Leader 副本的少数派不可用，不会影响系统的可用性和数据库的性能。如果少数派故障中有 Leader 副本，OceanBase 集群能够保证从剩余副本选出唯一新主提供数据服务，主要基于 OceanBase 集群的搭建部署模式，如果 OBServer 节点的多个 Zone 分布在不同机房、不同城市时，通过 OceanBase 集群的分布式选举加上 OceanBase Paxos Clog 同步就可以达到跨机房高可用或者是跨城市的高可用方案。 | | 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。当主集群出现计划内或计划外（多数派副本故障）的不可用情况时，备集群可以接管服务，并且提供无损切换（RPO = 0）和有损切换（RPO > 0）两种容灾能力，最大限度降低服务停机时间。 OceanBase 集群支持创建、维护、管理和监控一个或多个备集群。备集群是生产库数据的热备份。管理员可以选择将密集型只读业务操作分配到备集群，以便提高系统的性能和资源利用率。 | ## OceanBase 数据库如果少数派宕机会发生什么？多久可以恢复？ OceanBase 数据库利用了基于 Paxos 分布式一致性协议保证了在任一时刻只有当多数派副本达成一致时，才能推选一个 Leader, 保证主副本的唯一性来对外提供数据服务。如果正在提供服务的 Leader 副本遇到故障而无法继续提供服务，只要其余的 Follower 副本满足多数派并且达成一致，就可以推选一个新的 Leader 来接管服务，而正在提供服务的 Leader 自己无法满足多数派条件，将自动失去 Leader 的资格。当 Leader 副本出现故障时，Follower 能在多长时间内感知到 Leader 的故障并推选出新的 Leader，这个时间直接决定了 RTO 的大小。 OceanBase 数据库的选举模型是基于 Paxos 重新设计的选举方案，由同日志流的多副本进行共识协商，结合各副本优先级选出唯一的主副本。当选举成功后，每个副本会签订认定Leader 的租约（Lease）。在租约过期前，Leader 会不断发起连任，正常情况下能够一直连任成功。如果 Leader 没有连任成功，在租约到期后会周期性的发起无主选举，保证副本的高可用。 在三副本（全能副本）场景下，当一个副本出现异常（比如说该节点机器故障，OBServer 节点下线等单点故障），OceanBase 数据库选举模块能够做到：如果原主副本连任成功，原主可以连续提供主副本服务；如果原主副本下线，Leader 连任失败，OceanBase 数据库进行无主选举，新主上任的时间在 8s 内完成。 同时，OceanBase 数据库通过 Paxos 协议实现了多数派 Clog 强一致同步持久化，在 Paxos 组中任意少数派副本发生故障的情况下，剩下的多数派副本都能保证有最新的 Clog，因此就能避免个别硬件故障带来的数据损失，保证了数据可靠性。 ## OceanBase 数据库选举如何避免脑裂问题？ 在高可用方案中，一个经典的脑裂（Split Brain) 问题： 如果两个数据副本因为网络问题互相不知晓对方的状态，并且分别认为各自应当作为主副本提供数据服务，那么这时候就会出现典型的脑裂现象，最后会导致系统混乱，数据损坏。OceanBase 数据库利用了 Paxos 协议中的多数派共识机制来保证数据的可靠性以及主副本的唯一性：在任一时刻只有多数派副本达成一致时，才能推选一个 Leader。如果正在提供服务的 Leader 副本遇到故障而无法继续提供服务，只要其余的 Follower 副本满足多数派并且达成一致，他们就可以推选一个新的 Leader 来接管服务，而正在提供服务的 Leader 自己无法满足多数派条件，将自动失去 Leader 的资格。 因此，我们可以看到 OceanBase 数据库的分布式选举在高可用方面有明显的优势：从理论基础上就保证了任一时刻至多有一个 Leader，彻底杜绝了脑裂的情况。由于不再担心脑裂，当 Leader 故障而无法提供服务时，Follower 可以自动触发选举来产生新的 Leader 并接管服务，全程无须人工介入。这样一来，不但从根本上解决了脑裂的问题，还可以利用自动重新选举大大缩短 RTO。当然，这里面还有一个很重要的因素，那就是 Leader 出现故障时，Follower 能在多长时间内感知到 Leader 的故障并推选出新的 Leader，这个时间直接决定了 RTO 的大小。 ## OceanBase 集群当多数派失败的时候是否依旧可以服务？ 当 OceanBase 集群中多数派失败，那么对应的分区是无法对外提供数据服务的。为了保证数据的高可用，在整个系统架构设计和运维时，还应当考虑和优化两个副本不相关的连续故障发生的时间。最终保证 MTTF（Mean Time To Failure）应当相较于故障的修复时间 MTTR (Mean Time To Repair)足够的小，以保证整个数据服务的高可用性。当 OceanBase 集群多数派失败的时候，在保留问题分析需要的信息和日志前提下，应当尽快采取应急措施将集群尽快恢复可用。 ## OceanBase 集群的副本自动补齐功能是如何工作的，副本自动补齐是否能够保证即使在节点宕机的情况下，相应的分区副本依旧齐全？ 当 observer 进程异常终止，若终止时间小于`server_permanent_offline_time`，则不作处理，此时有些分区的副本数只有 2 个了（三副本情况下）；当终止时间超过`server_permanent_offline_time`时，则对该Server 做永久下线处理，OceanBase 集群会在同个 Zone 的其他 Server 开辟区域（在资源充裕的 Server 下），维持副本个数。当有足够的资源时就会发起 Unit 迁移。 ## OceanBase 集群是否支持多机房多地区的部署方式，在部署的时候有哪些基础设施的要求，应该如何选择方案？ 在 OceanBase 集群的搭建中，允许将多个副本（节点）分散到多个机房、多个城市中，跨机房/跨城市实现Paxos 组。在选择多机房，多城市集群架构时，通常也是为了获取机房级容灾甚至是城市级容灾的能力。从技术上来说，只要是支撑 OceanBase 集群不同副本节点的基础设施足够好, 在合理的副本分布下，OceanBase 集群就可以将数据分布在不同的节点上对外提供数据服务。通常情况下，进行多机房/多城市的的部署方案最重要的是考虑业务和各方面产生的架构需求。因为多机房/多城市的部署方式也会直接带来整个系统成本的大幅提高（比如是跨城市的网络专线部署等等）。所以不同的部署方案是一个基于成本、需求、产品能力、方案可行性等多个维度的权衡结果产出。 从技术上来讲，可以解决机房级容灾或者城市级容灾的集群解决方案有： - 同城三机房三副本部署 - 同城 3 个机房组成一个集群（每个机房是一个 Zone），机房间网络延迟一般在 0.5 ~ 2 ms 之间。 - 机房级灾难时，剩余的两份副本依然是多数派，依然可以同步 Redo-Log 日志，保证 RPO=0。 - 无法应对城市级的灾难。 ![1](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer-enterprise/V4.1.0/4.deploy/1.deploy-scheme/plan-optimization/1.1-3.png) - 三地五中心五副本部署： - 三个城市，组成一个 5 副本的集群。 - 任何一个 IDC 或者城市的故障，依然构成多数派，可以确保 RPO=0。 - 由于 3 份以上副本才能构成多数派，但每个城市最多只有 2 份副本，为降低时延，城市 1 和城市 2 应该离得较近，以降低同步 Redo-Log 的时延。 - 为降低成本，城市 3 可以只部署日志型副本（只有日志）。 ![2](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer-enterprise/V4.1.0/4.deploy/1.deploy-scheme/plan-optimization/2.3-5.png) 在实际的部署方案中，OceanBase 集群也根据客户的需求定制过同城双机房和两地三中心的方案。两种部署方案都各自解决了一部分相应场景对于系统高可用的需求，但是同时也存在一定容灾能力的短板。在一定时期有可能作为系统架构的中间态成为客户在初始部署的选择，客户也有可能参与 OceanBase 主备库架构搭配使用一起达到期望的容灾能力。具体的方案探讨需要考虑多个因素和方面，如果有实际具体的场景，请联系 OceanBase 数据库技术架构师进行方案讨论和对接。 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线