集群管理 FAQ

选举 FAQ

OceanBase 集群的选举有哪几种，分别是由谁发起的？

OceanBase 集群在实现上主要包含无主选举、有主连任、有主改选(切主)这几个部分。其中无主选举是在集群启动或者 Leader 连任失败的时候才会进行。除了手动切主以及无主选举，其他的自动选举均是由 Paxos 组的 Leader 发起的。在组成了一个 Paxos 集合的 3 个成员副本中，切主动作由每个 Paxos 组的 Leader 控制，当 Leader 在续约流程中发现某个 Follower 比它的优先级更高时它就执行切主流程“让贤”。

什么样的副本可以参与选举？

OceanBase 集群的副本类型有全能型副本（FULL）、日志型副本（LogOn）、只读型副本 (ReadOnly）。其中日志副本和全功能副本参与选举投票。 只有全能型副本可以作为选举中 Leader 的候选者（Candidate)，变为主提供数据库服务。日志型副本可以提供日志服务但不是选举中 Leader 的候选者，不能被选举为主提供数据服务。

OceanBase 集群的选举模块的对基础设施的要求有哪些？

从 OceanBase 数据库 4.0.0 版本开始，选举对于时钟偏差没有要求，由于 OceanBase 集群采用强 Leader 模式，有租约时长的限制，默认设置下，租约时长为 4s，要求环境中任意两副本的应用层最大单程消息延迟不可超过 1s。但是在实际环境中由于网络分层的原因以及操作系统和上层应用的实现问题，IP 层的消息延迟会在应用层中被放大，而且这个放大的倍数没有指标可以参考，因此需要保证环境中的 ping 延迟尽量低。

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 内完成。

如果多数派副本宕机，OceanBase 集群的选举模块是否还可以选出 Leader 副本保证高可用？

当 OceanBase 集群中的多数派副本同时宕机时，OceanBase 集群无法再选举出主副本（Leader 副本）对外提供数据服务。

OceanBase 集群的选举模块是否需要做任何运维操作？

实际上，OceanBase 数据库没有对用户提供任何干预选举模块的方法或者接口，比如控制多数派的选举规则等。 在集群的正常运行过程中，不需要数据库管理员或者管理员进行任何人为的操作或者干预来控制或影响 OBServer 节点的选举模块完成其功能。在进行集群管理动作时，比如说停掉 OBServer，上线新的 OBServer，修改租户的 Primary Zone 设置等，都有可能会触发选举模块进行选举，以保证租户中的数据副本存在主副本作为 Leader 对外提供数据服务。目前为止没有任何的系统运行情况需要管理员直接对选举模块进行运维干预。

在选举中哪个副本会被选为主，如何保证选举到的 Leader 副本是更好的选择？

OceanBase 集群的选举会比较副本的优先级，保证尽量选出来一个健康状况更好更优的机器作为 Leader 副本。目前 OceanBase 集群的优先级主要考虑了副本是否是 Leader 的合法候选人，副本健康分，副本成员列表版本号，以及副本日志同步状况四个维度。这也意味着通过 OceanBase 集群自动触发的选举最终会让更健康，版本推进最新的合法选举副本被选为主。在 OceanBase 数据库 4.0.0 版本中，无主选举和有主改选优先级统一，成员变更版本号作为最高优先级，同时也是唯一一个内嵌在选举协议内部的优先级，版本号大的副本不会给比自己版本号小的副本投票。

在什么情况下会有自动切主？

Leader 副本在延续租约的过程中，会周期性的与 Follower 副本进行交互，在交互过程中如果发现 Follower 副本具备更高的优先级，Leader 就会触发切主动作，“让位”给对应的 Follower。常见发生切主的原因有：

• primary_zone 发生变更。

• 发生 Stop Server/Stop Zone 的操作。

• 发生 OBServer Stopped（即 kill -15）的操作。

• 发生日志流的迁移。

如何查看触发切主的原因？

可以通过 DBA_OB_SERVER_EVENT_HISTORY 视图来查看某个日志流选举模块发生的事件。

如何查看无主选举？

可以通过 DBA_OB_SERVER_EVENT_HISTORY 视图查看，表里记录了所有日志流的所有选举事件，包括无主选举、切主、成员变更等。

OceanBase 集群报错 -4038 是什么含义？

4038 错误码的定义是 not master，在发生 4038 错误后有两种可能：

1. 当前 Leader 存在，但是 Leader 不在运行进程所在的 Server 上(需要排查上层模块问题)。

2. 当前 Leader 不存在。根据排查问题的经验基本上是网络连通状态有问题（这里指的是日志流级别的连通状态），例如：

   • 因为租户没有内存接收不到消息，但是还能发送消息，导致单向网络连通。

   • 因为工作队列积压导致无法接收消息。

   • 因为 Server 处于 Stop 状态无法接收消息。

   • 其他原因导致的网络连通性问题。

CLOG 模块会影响副本选举吗，是如何影响的？

OceanBase 数据库 V4.0.0 版本 clog 的异常状态会作为选举优先级的一部分，Leader 的 clog 如果出现异常将会降低 Leader 选举优先级，当有 Follower 的优先级比 Leader 更高时 Leader 将会触发切主。

CLOG 在发生主动卸主后会重新选主么？

OceanBase 数据库 V4.0.0 版本不再有 clog 发起的主动卸任动作，如果 clog 写盘 hung 住，将会记录 failure 事件，Leader 的优先级会被降低，其后会自动选择最优副本直接切主，切主事件将会记录在 DBA_OB_SERVER_EVENT_HISTORY 视图中。

CLOG FAQ

OceanBase CLOG 同步压缩功能中不同的压缩算法有什么区别，应该怎么选择？

OceanBase 数据库通过 log_transport_compress_func 来控制事务日志同步的压缩算法，默认为 lz4_1.0。在开启日志同步压缩后，clog 会按照算法来对日志进行压缩传输。目前 clog 支持的压缩算法有 lz4_1.0，zstd_1.0，zstd_1.3.8。在不同的压缩算法下会对 clog 进行不同比例的压缩并传输，进而减轻对带宽的压力。但与此同时，由于 clog 的处理都需要先进行压缩操作，所以会带来一定的性能代价。 在不同的场景下，不同压缩算法带来的压缩收益以及性能代价会有不相同。默认值为 lz4_1.0 压缩算法是在保证可控的性能代价下相对能够带来较大的压缩比例。因此 OceanBase 数据库的配置参数 log_transport_compress_func 设置了默认值为 lz4_1.0。如果在不同的场景下，有更高的压缩比率追求或者能够容忍更高程度的性能代价，可以选择不同的压缩算法。

事务执行到提交的过程中，数据更改是如何提交到 MemStore，持久层并保存在 CLOG 中的？

当一个数据库事务包含了 DML 的请求，数据更改会更新到 Leader 副本的 MemTable 中。在事务 Commit 成功以后，OceanBase 数据库的事务处理能够保证数据更改在多数派的 clog 中落盘并会回放到 Follower 副本的 MemStore 中。在 OceanBase MemStore 的使用超过一定阈值之后，会进行转储，将 MemStore 持久化到 SSTable 上。 下面简单介绍在存储层（MemTable，SSTable）以及 clog 层所发生的关键动作：

1. 应用发起一个事务 Tnx1；

2. 假设 Tnx1 事务中会顺序执行 DML 请求 DML1 和 DML2；

3. DML1 和 DML2 通过执行 SQL 层，更新事务的上下文，并将数据更改更新到 MemTable 中；

4. DML1 和 DML2 在 SQL 层执行成功，应用程序发起 COMMIT，Tnx1 进入事务提交阶段；

5. Leader 副本发起 clog 落盘，并同时将 clog 同步到 Follower 副本;

6. 当 Leader 和 Follower 形成 clog 多数派落盘时，事务 Commit 成功，返回应用端;

7. Follower 副本在接收到 clog 且落盘后，还要等待 Leader 副本发送的“clog已完成多数派落盘”的确认消息，才会开始异步回放，将 clog 的内容回放到 MemStore 为弱一致读提供数据服务。

如果 OBServer 节点的滑动窗口卡住或者满掉, 会出现什么报错，会造成什么后果，应当如何调优？

clog 滑动窗口（Sliding Window） 满主要分为下面两种情况：

从整体上来说，如果 clog 滑动窗口满了，会影响 clog 的持久化的推进。这种情况下，应用端会感受到 slow trans 或者"锁等待"（日志中会出现 -6005 和 lock_for_write conflict.*\-4023）等问题，性能也会受到明显影响。分析的思路有如下几种:

• 分析 clog 提交写入是否大幅的增长变化，比如系统新上线一个高并发的跑批场景，对 clog 滑动窗口的并发压力非常大，那么需要先从业务逻辑检查高并发的跑批是否是业务需要的，如果业务允许，可以尝试降低并发测试问题进行缓解。这通常是比较安全且最快得到优化效果的一条路径。

• 如果业务并发并没有突然的激增，但是遇到了该问题，需要诊断 clog 滑动窗口的滑出是否有瓶颈，比如遇到 Follower 由于转储慢内存不足，日志回放不进内存，有可能导致 clog 滑动窗口满掉，如果遇到该种场景，需要联系 OceanBase 数据库技术支持进行分析。

• 拆分热点分区

由于所有的滑动窗口大小都是以分区为单位设置的，显然数据的热点越集中就越容易把滑动窗口撑满，因此将数据的热点打散到多个表或者分区，可以有效降低滑动窗口满的概率。除了我们经常关注的主表热点分区之外，还要特别关注“全局”索引的热点情况，包括：

• 全局“非分区”索引，索引数据集中在一个分区上；

• 分区键不合适的全局分区索引，比如索引键上的 NDV 过小，或者有严重的数据倾斜（某些键值的记录数过多），也会导致索引数据集中在少量甚至一个分区上。

CLOG reconfirm 失败的场景以及失败后有什么影响？如何分析 CLOG reconfirm 失败的情景

OceanBase 数据库是一个分布式数据库，分区要正常提供读写服务，必须选出一个 Leader，整个选主的流程大致如下：

1. OceanBase 数据库的选举模块选出副本 Leader。

2. clog 模块从选举模块得知当前 Leader，Leader 在上任前执行 clog reconfirm 过程, 确保数据是最新的。

3. Leader 执行 Takeover 等操作后，正式上任。

如果新主从 OceanBase 数据库选举模块已经被选出，但是 clog reconfirm 由于一些原因导致失败了，那最终对应的数据分区也是无法提供数据服务。

clog reconfirm 过程的主要目的是对于滑动窗口中遗留的未确认日志进行重确认，并同步给 Follower 副本。OceanBase 数据库在事务提交的过程中，如果 clog 已经成功同步到了多数派，事务就已经提交成功，若此时 Leader 宕机，有可能还在线的副本里就有 clog 还未完成确认回放到 MemTable。那么 clog reconfirm 就保证了在 Leader 切换的场景下，所有副本的 clog 都已经完成了确认，还可以保证多数派的 clog 同步一致状态，保证接下来的事务提交不受影响。clog reconfirm 过程包含如下几个阶段：

在上面 6 阶段中的关键阶段会将日志打印到 observer.log，例如： 阶段 2 收到多数派的回复的标志日志是（如果无法看到该日志说明本阶段被卡住了）：

[20XX-XX-XX 20:28:06.142985] INFO  [CLOG] ob_log_reconfirm.cpp:598 [127240][Y0-0000000000000000] [lt=25] max_log_ack_list majority(partition_key={tid:1099511627777, partition_id:0, part_cnt:1}, majority_cnt=2, max_log_ack_list=1{server:“10.101.XXX.XXX:261XXX”, timestamp:-1, flag:0})

单条 clog reconfirm 过程的超时时间是 10s，即如果 10s 没有执行完会打印 ERROR 级别的超时日志，关键字为 is_reconfirm_role_change_or_sync_timeout。clog reconfirm 通常由于卡在如上各个阶段而超时，卡住的原因主要有：无法提交回放、网络不通、日志盘满等。 clog reconfirm 卡住的主要原因和关键日志信息有

如果根据以上诊断方法无法排查出 clog reconfirm 失败的原因，那么请联系 OceanBase 数据库技术支持进行诊断。

CLOG 满盘应该如何进行问题分析和应急操作？

对于分区数多、写入压力大的集群，如果转储慢（卡住）、或者租户 Unit 规格异构，那么可能导致部分副本的 clog 回收不及时导致盘空间达到 95%，此时 OBServer 节点会自动停写，这样这台机器上会有大量副本不同步。 正常情况下，clog 盘空间会维持在 80% 左右，一旦超过 80%，说明日志文件回收慢或者卡住了，clog 文件回收的条件是：该文件中所有分区日志对应的数据都已经转储到 SSTable 中。因此通常导致 clog 盘满的原因是部分分区转储卡住。 在 clog 盘空间开始报警之后，根据下面的步骤确认阻塞回收的分区：

1. 从以下命令的结果中查看：

   grep  can_skip_base  observer.log 
   

   • 从搜索结果中查找 need_record 为 True 的记录，里面有 partition_key，表示这个分区的日志无法回收。

   • 从报警日志附近时间点开始搜索，搜索结果中的分区就是当前阻塞回收的分区，拿到其中的 partition_key；

2. 利用上面的 partition_key 去搜索该分区的日志：

   grep  partition_key  observer.log
   

   通过日志分析它转储位点未推进的原因。

应急手段

在出现了 clog 满盘的情况下，如果已经影响到多数派节点，影响了事务提交，即整个系统都出现了 Hang 和无响应的情况，业务侧还有大量并发 DML 的事务涌入，建议先将业务负载暂停，恢复 clog 服务。

如果 clog 满盘的操作只影响了少数派，请先快速分析节点是否有 IO 层，网络层（基础设施层）的重大瓶颈。

若有可将少数派节点先隔离后将 IO 瓶颈和网络瓶颈进行解决。

如果没有 IO 层和网络层（基础设施层）的瓶颈，仍然可能在少数派节点上出现问题，请联系技术支持人员协助排查。

可能原因

• 运维问题。

  clog 盘所在空间被其他用户的文件占用，导致可以利用的空间不足。

• 转储持续失败是 clog 满盘最常见的原因。

  当 clog 中涉及的分区数据已经全部转储到 SSTable 中，且 partition 的元信息已经持久化宕机重启起始位点时，clog 文件就可以进行回收。所以，如果转储不成功，宕机重启 clog 起始回放位点不推进，CLOG 文件是无法进行回收的。因转储持续失败的原因场景和具体原因逻辑相较比较复杂，遇到该种情景，请联系 OceanBase 数据库技术支持进行介入诊断。

如果 OBServer 节点重启时在初始化 CLOG 失败会报什么错，如果 OBServer 节点启动时初始化失败报错应当如何操作恢复系统?

存储 FAQ

OceanBase 数据库的存储引擎和传统数据库有什么不一样的地方？

OceanBase 数据库采用了一种读写分离的架构，把数据分为基线数据和增量数据。其中增量数据放在内存里（MemTable），基线数据放在 SSD 盘（SSTable）。对数据的修改都是增量数据，只写内存。所以 DML 是完全的内存操作，性能非常高。读的时候，数据可能会在内存里有更新过的版本，在持久化存储里有基线版本，需要把两个版本进行合并，获得一个最新版本。同时在内存实现了 Block Cache 和 Row Cache，来避免对基线数据的随机读。当内存的增量数据达到一定规模的时候，会触发增量数据和基线数据的合并，把增量数据落盘。同时每天晚上的空闲时刻，系统也会自动每日合并。

数据在 OceanBase 数据库中是如何存储的？

OceanBase 数据库的数据文件以宏块（Macro Block）为单位组织数据，每个宏块大小为 2 MB。宏块内部又划分出很多个16 KB（压缩前的大小）大小的微块（Micro Block），而每个微块里面包含多个行（Row）。OceanBase 数据库内部 IO 的最小单位是微块。

应该使用分区表吗？

是否使用分区表，可以参考以下信息进行判断：

• 如果一张表的数据量在可预期的未来会突破 200 GB，建议使用分区表。

• 如果表具有比较明显的时间周期，建议使用分区表。

在 OceanBase 数据库中，局部索引与全局索引在实现上的区别是什么？

局部索引与全局索引的区别如下：

• 局部索引：和单表或者分区表最小子分区绑定在一起，不会在 OceanBase 数据库系统租户中创建额外的分区记录，所有基于局部索引的 SQL 基本都是本地执行。

• 全局索引：需要在 OceanBase 数据库系统租户中创建额外的一个分区记录，可以理解为另外一张表，占用额外的分区配额。全局索引可以有自己的分区策略，Locality 也不与主表绑在一起，即使是单表，全局索引也可以与主表分别存储在不同的节点上，当然这样也更容易使 SQL 成为分布式 SQL。