数据库学习Q&A 034：OceanBase 数据库中，集群的选举模块是如何保证 RTO 不大于 8s 的？

在默认设置下，OceanBase 集群中选举 Leader 的租约时长为 4s，当 Leader 宕机后，最长可能延迟 4s 的时间直至其租约到期，多数派副本在等待租约到期后会尽快开启下一轮选举，选出参考优先级后集群中最适合当选的副本成为新的Leader。同时选举模块为 Leader 宕机后的无主选举做了特殊优化，选举层 Leader 宕机后的平均无主时间约等于租约时长。 需要注意的是从选举成功到集群服务恢复之间，还需要一系列额外的工作流程：如新 Leader 需进行 Paxos 的 reconfirm 阶段补全日志（该阶段的耗时取决于新Leader 落后于旧 Leader 的日志数量，选举保证尽可能不选到日志落后过多的副本）；在新 Leader 上恢复尚未提交的旧 Leader 的事务状态；向 Root Service 汇报 Leader 的位置信息，如果配置了 obproxy 还需要等待 Proxy 更新正确 Leader 位置信息后才能将后面的 SQL 语句路由到正确的 Leader 位置上。 OceanBase 集群选举模块能够做到：如果原主副本连任成功，原主可以连续提供主副本服务；如果原主副本下线，Leader 连任失败，OceanBase 集群进行无主选举，新主上任的时间在 8s 内完成。在 8s 的 RTO 时间内，选举层面将会消耗约 4s 的时间，剩余时间用于恢复其他阶段。其他阶段的恢复流程尽管和日志的数量差、未提交事务的规模呈正相关，但通常各阶段都不超过百 ms，总体的服务恢复时间可以保证在 8s 内完成。