OB 数据库是一个分布式数据库,少数派宕机会发生什么?多快可以恢复?应如何避免脑裂问题?

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,因此就能避免个别硬件故障带来的数据损失,保证了数据可靠性。

在高可用方案中,一个经典的需要面对的问题就是脑裂问题: 如果两个数据副本因为网络问题互相不知晓对方的状态,并且分别认为各自应当作为主副本提供数据服务,那么这时候就会出现典型的脑裂现象,最后会导致系统混乱,数据损坏。 OceanBase 数据库利用了 Paxos 协议中的多数派共识机制来保证数据的可靠性以及主副本的唯一性:在任一时刻只有多数派副本达成一致时,才能推选一个 Leader。如果正在提供服务的 Leader 副本遇到故障而无法继续提供服务,只要其余的 Follower 副本满足多数派并且达成一致,他们就可以推选一个新的 Leader 来接管服务,而正在提供服务的 Leader 自己无法满足多数派条件,将自动失去 Leader 的资格。因此,我们可以看到 OceanBase 数据库的分布式选举在高可用方面有明显的优势:从理论基础上就保证了任一时刻至多有一个 Leader,彻底杜绝了脑裂的情况。由于不再担心脑裂,当 Leader 故障而无法提供服务时,Follower 可以自动触发选举来产生新的 Leader 并接管服务,全程无须人工介入。这样一来,不但从根本上解决了脑裂的问题,还可以利用自动重新选举大大缩短 RTO。当然,这里面还有一个很重要的因素,那就是 Leader 出现故障时,Follower 能在多长时间内感知到 Leader 的故障并推选出新的 Leader,这个时间直接决定了 RTO 的大小。