OB有问必答 | OceanBase 如何做到 RTO < 30秒?

简介: “OB有问必答”是OceanBase最新上线的互动类栏目,每周围绕一个关于分布式数据库的议题为大家详细展开解答,今天我们围绕服务可用性话题讨论,如果你有任何感兴趣的问题,欢迎留言,我们会每周选取一个问题为大家详细解答。

上一期我们谈到了 OceanBase 如何保证数据的可靠性,以此为前提,服务可用性就成为了另一个焦点:如果某个服务节点发生了故障,用户不但希望数据不丢(RPO=0),而且希望服务能够尽快恢复(RTO 越小越好)。

在历史上,在传统数据库的高可用能力不足时,有很多种高可用方案是结合了硬件和操作系统的高可用能力,不过这些方案通常在架构上过于复杂,而且无法在数据库层面保证数据的一致性。随着数据库内置的高可用能力逐渐完善,用户也转向了数据库自带的高可用方案,典型代表就是“主从热备”技术,比如Oracle Data Guard、IBM DB2 HADR 等。

但是,主从热备技术在高可用上有一个很难解决的问题:当主节点故障的时候,如何让备用节点快速接管服务。如果让备用节点判断主节点的状态,并且在主节点故障时“自动”接管服务,那么就会面临一个致命的问题,就是“脑裂(Split-brain)”:备用节点和主节点同时提供服务了,两个节点间的数据将再也无法保持一致。

为了避免脑裂问题,数据库的主从热备机制都不会提供“备库自动接管服务”的能力,备库的接管动作要引入人工决策的流程,需要人为在备用节点发起服务接管的动作。这样一来,RTO 就会达到数十分钟甚至以小时计。为了避免脑裂问题,同时又减小 RTO,有些数据库产品引入了自动 failover 的机制,比如Oracle 数据库的 Fast-Start Failover(FSFO);但由于引入了额外的组件或者服务,整个解决方案的复杂度明显增大,而且这些组件或者服务自身的高可用又成了新的问题。总体来说,由于主从热备的本质没有发生改变,只是额外引入了第三方仲裁者的角色,所以这种方案并没有解决根本问题,也不能100%保证避免脑裂。

OceanBase 利用了 Paxos 协议中的多数派共识机制来保证数据的可靠性,在高可用方面,OceanBase 也利用了同样的机制。首先,根据 Paxos 协议,在任一时刻只有多数派副本达成一致时,才能推选一个leader,其余的少数派副本则不具备推选 leader 的资格。

其次,如果正在提供服务的 leader 副本遇到故障而无法继续提供服务,只要其余的 follower 副本满足多数派并且达成一致,他们就可以推选一个新的 leader 来接管服务,而正在提供服务的 leader 自己无法满足多数派条件,将自动失去 leader 的资格。因此,我们可以看到 Paxos 协议在高可用方面有明显的优势:

1)从理论上保证了任一时刻至多有一个 leader,彻底杜绝了脑裂的情况。

2)由于不再担心脑裂,当 leader 故障而无法提供服务时,follower 便可以自动触发选举来产生新的 leader 并接管服务,全程无须人工介入。

这样一来,不但从根本上解决了脑裂的问题,还可以利用自动重新选举大大缩短 RTO,可以说完美解决了主从热备技术在高可用上所面临的难题。

当然,这里面还有一个很重要的因素,那就是 leader出现故障时,follower 能在多长时间内感知到 leader的故障并推选出新的 leader,这个时间直接决定了RTO 的大小。在OceanBase中,为了能够及时感知Paxos 组中各个副本(包括 leader 和 follower)的状态,在各个副本之间会有定期探活的消息。另一方面,探活机制虽然能够检测到节点的故障,但是在网络不稳定的情况下,也可能由于偶发的探活消息丢包而产生“误报(False-alarm)”的情况。为了避免误报对系统稳定性带来的影响,OceanBase也采取了很多应对措施:

1)首先,探活消息的周期必须要合理。
如果周期太长就不能及时感知到节点故障,如果周期太短就会增大误报的概率,而且也可能会影响性能。目前在 OceanBase 中的探活总体耗时为10秒左右,确保能及时感知到节点故障,并且也不会频繁产生误报。

2)其次,要能够容忍偶发性的消息丢包,减小误报的概率。
具体来说,OceanBase 不会由于一次探活的失败就认定某个节点发生了故障,而是在连续多次尝试都失败后才确认真正的节点故障。这就有效避免了偶发性消息丢包所导致的误报。

3)如果真的发生了误报,需要将影响范围降到最小。
OceanBase 将 Paxos 组的粒度下沉到了表的分区一级,也就是每一个分区都会有一个 Paxos 组,用来维护这个分区的多个副本之间的 leader-follower 关系,如果由于少量网络丢包导致“某个分区”的探活消息没有收到回复,那么受影响的只是这个分区,同一台机器上的其它分区会照常工作,这就有效地控制了问题的影响范围。

4)某些特殊情况的处理。
举个例子,如果某台机器出现间歇性故障(比如网卡或者操作系统出了问题),导致这台机器频繁发生网络传输故障,就会使这台机器上所有的 leader 副本持续受到影响。这种情况下,OceanBase 可以通过设置特定参数限制这台机器暂时不参与 leader 选举,这样就有效地起到了隔离作用,避免了局部故障对整个集群的可用性造成持续影响。

在具备了上述这些处理机制后,OceanBase 目前已经能做到最多10秒钟检测到服务节点异常,并在10~30秒内完成服务的自动恢复。需要说明的是,具体的恢复时间和遇到问题的机器个数、表的分区个数、故障类型(机器硬件故障、网络设备故障等)都有密切的关系,所以上面说的服务恢复时间只是作为一个参考值,在某些特殊情况下也可能发生偏差。

相关文章
|
6月前
|
SQL 流计算 OceanBase
OceanBase CDC从热OB库采集过来的Tinyint(1)类型会默认转换成Boolean,请教一下,如果想转换成int类型,有什方法么?
【2月更文挑战第25天】OceanBase CDC从热OB库采集过来的Tinyint(1)类型会默认转换成Boolean,请教一下,如果想转换成int类型,有什方法么?
175 3
|
4月前
|
DataWorks API 数据库
DataWorks操作报错合集之在使用 OceanBase (OB) 作为数据源进行数据集成时遇到报错,该如何排查
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
|
6月前
|
存储 关系型数据库 数据处理
OceanBase数据库常见问题之start ob出错如何解决
OceanBase 是一款由阿里巴巴集团研发的企业级分布式关系型数据库,它具有高可用、高性能、可水平扩展等特点。以下是OceanBase 数据库使用过程中可能遇到的一些常见问题及其解答的汇总,以帮助用户更好地理解和使用这款数据库产品。
|
4月前
|
DataWorks 关系型数据库 MySQL
DataWorks操作报错合集之从OceanBase(OB)数据库调度数据到MySQL数据库时遇到连接报错,该怎么办
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
|
SQL 运维 负载均衡
漫谈OB | OceanBase 在海量数据和高并发下的应用实践
数据库选型用 OceanBase 的原因很多,传统数据库上的业务做分布式数据库选型,其中一类原因是数据库遇到瓶颈。这类客户业务特点之一是数据量和访问量都很大。本文总结业务数据量和访问量大的业务场景下的OceanBase实践经验。 💡 本文适用于 OceanBase 企业版和社区版
1077 0
漫谈OB | OceanBase 在海量数据和高并发下的应用实践
|
存储 缓存 NoSQL
OB有问必答 | LSM Tree的技术原理是什么?OceanBase的存储引擎为什么基于LSM Tree?
相对于传统的page based数据库存储方式,OceanBase使用了现在非常流行的LSM Tree作为存储引擎保存数据的基本数据结构,这在分布式的通用关系型数据库当中是很少见的。今天我们就来为大家详细解读下LSM Tree的技术原理。
OB有问必答 | LSM Tree的技术原理是什么?OceanBase的存储引擎为什么基于LSM Tree?
|
存储 SQL 缓存
|
存储 SQL Oracle
OB有问必答 | 分区是什么?在OceanBase中起到了什么作用?
分区是一种水平拆分方案,是数据同步的最小单元,是高可用的最小单元,是高可用的最小单元。
|
Oracle 关系型数据库 MySQL
OB有问必答 | OceanBase主备怎么同步?是强一致吗?
OceanBase集群里机器通常没有主备之说,数据同步是发生在每个分区的主副本到备副本之间的。不同分区的主备同步是独立进行的。同一个分区(数据)的主副本位置不是固定的(但受策略控制),只会出现在其中一个Zone的其中一台机器上,但是不同分区的主副本是可以位于不同Zone或者不同机器上。

热门文章

最新文章