日志同步问题

本文介绍日志同步的基本原理及常见问题。

OceanBase clog 的全称是 OceanBase Commit Log，是 OceanBase 日志服务的核心。日志服务是 OceanBase 数据库的基础组件，承担着支持事务的原子性、持久性、隔离性以及数据库高可用等核心功能。在数据库提交的过程中通过 Paxos 协议保证多数派 clog 落盘，而少数派 clog 日志内容也会最终会持久化在硬盘上。OceanBase 数据库有自动的日志回收机制来保证日志盘的持续可写入。

常见的 clog 问题包括：clog 盘满、clog 回放卡住、clog 同步延迟、clog 滑动窗口满、clog reconfirm 失败等，本文将介绍 clog 盘满的排查定位方式。

排查手段

视图 GV$OB_LOG_STAT/V$OB_LOG_STAT 展示了日志模块的状态，典型的使用场景：

• 查询日志流是否有 Leader，Leader 所在的副本。
• 查询日志流的成员列表，Paxos 副本数。
• 查询副本同步状态。
• 查询日志流日志的可回收位点。
• 查询日志流允许提供日志消费服务的范围（包括 LSN/SCN）。
• 查询日志模块的访问模式。
• 其他问题定位需求等。

重要配置项

clog 盘满

正常情况下，clog 盘空间使用率会维持在一定阈值，在超过设定阈值后，会将可以回收的日志文件回收掉。一旦超过设定阈值，说明日志文件回收慢或者卡住。

clog 文件回收的条件：该文件中所有分区日志对应的数据都已经转储到 SSTable 中。因此通常导致 clog 盘满的原因是部分分区转储卡住。

排查步骤

在 clog 盘空间开始报警之后，根据下面的步骤进行排查：

1. 如何判断日志盘是否写满。

   可以通过 GV$OB_UNITS 视图查看日志流的日志盘使用是否超过磁盘回收水位线（默认是 80%，可以通过配置项 log_disk_utilization_threshold 调整），具体 SQL 语句为：

   select tenant_id, svr_ip, svr_port, 
   LOG_DISK_IN_USE/1024/1024/1024 LOG_DISK_IN_USE_G, 
   LOG_DISK_SIZE/1024/1024/1024 LOG_DISK_SIZE_G, 
   LOG_DISK_IN_USE*100/LOG_DISK_SIZE LOG_DISK_USED_PERCENTAGE 
   from gv$ob_units;
   

2. 确认租户下哪些日志流存在异常。

   如果发现有租户的日志盘使用超过租户日志盘规格的 80%，需要进一步确认租户下哪些日志流存在异常。其中 (END_LSN - BASE_LSN) 表示对应日志流还不能回收的日志量（字节），当使用超过 128MB，且同时存在日志盘满的情况，那么该日志流阻塞了日志回收，具体 SQL 语句为：

   select TENANT_ID, LS_ID, SVR_IP, ROLE ,
   (end_lsn-base_lsn)/1024/1024 
   from gv$ob_log_stat;
   

   若相关视图无法访问，也可以通过系统日志查询，例如：

   grep 'ERROR.*Txxxx_PalfGC' observer.log.* 
   [2022-07-19 21:34:37.191950] ERROR [PALF] try_recycle_blocks (palf_env_impl.cpp:637) [147234][T1010_PalfGC][T1010][Y0-0000000000000000-0-0] [lt=21] clog disk space is almost full(total_size(MB)=165888, used_size(MB)=132710, used_percent(%)=80, warn_size(MB)=132710, warn_percent(%)=80, limit_size(MB)=157593, limit_percent(%)=95, maximum_used_size(MB)=74026, maximum_log_stream=1006, oldest_log_stream=1004, oldest_timestamp=1658223124759857784) BACKTRACE:0x434d92e 0xc1a323a 0xc194b93 0x44726d4 0x447239f 0x44721cb 0x4471ffd 0x45b102c 0x45b0339 0x43671aa 0x4365b6d 0x521ebf9 0xc396ec6 0xc391b19 0x7f337d6bfe24 0x7f337cf68f1c
   

   其中：

   • maximum_log_stream：表示使用日志盘空间最多的日志流。
   • oldest_log_stream：表示日志最旧的日志流。

3. 日志盘满根因排查。

   1. 确认日志回放/回调是否存在问题，根据上一步获取到的租户、日志流以及盘满机器进一步排查。

      • 如果副本角色是 Leader，需要进一步确认日志同步异常的原因。

        • 如果 Leader 副本本地写盘位点未推到最新，可能写盘慢或者卡了。

        • 如果 Leader 副本本地写盘位点推到最新，说明本地写盘已完成，需要排查 Follower 副本是否发生异常。

          • 比较常见的异常是 Follower 上日志盘满，导致无法接受新的日志。可以在落后的 Follower 上搜索是否有盘满的相关日志。
          • 可能是 Leader 和 Follower 之间的 RPC 通信发生异常，例如 Follower 上 RPC 请求队列发生积压。可以在落后的 Follower 上搜索是否有 RPC 队列积压的相关日志。
          • 也可能是 RPC 处理请求时分配内存失败。可以在落后的 Follower 上搜索是否有内存分配失败的相关日志。

      • 如果副本角色是 Follower，需要进一步确认日志回放异常的原因。

        • 回放服务负责 Follower 副本回放日志，在 OBServer 出现非预期错误时会阻止后续日志的回放，防止出现更严重的正确性问题。日志回放异常不一定意味着回放服务自身的问题，需要根据错误日志定位到具体的模块。

   2. 确认冻结是否存在问题。

      冻结流程相关的系统日志如下：

      # 系统冻结开始
      receive minor freeze reques
      
      # 系统冻结结束
      finish minor freeze request
      
      # 租户级冻结开始
      [TenantFreezer] tenant_freeze start
      
      # 租户级冻结成功
      [TenantFreezer] succeed to freeze tenant
      
      # 租户下某个日志冻结失败
      [TenantFreezer] fail to freeze logstream
      
      # 分区级冻结开始
      [TenantFreezer] tablet_freeze start
      
      # 分区冻结成功
      [TenantFreezer] succeed to freeze tablet
      
      # 分区冻结失败
      [TenantFreezer] fail to freeze tablet
      

   3. 确认转储是否存在问题。

应急手段

• 如果已经影响到多数派节点，影响了事务提交，即整个系统都出现了 hang 和无响应的情况。如果此时上层应用依然有大量事务写入，建议先将应用负载暂停，然后执行下述恢复 clog 服务的操作。

• 如果只影响到少数派节点，需要快速分析节点是否有 IO 层，网络层（基础设施层）的资源瓶颈。

  • 如果有资源瓶颈，可将少数派节点隔离后然后解决资源瓶颈问题。
  • 如果没有资源瓶颈，可以在异常节点上执行下述恢复 clog 服务的操作。

恢复操作：

1. clog 盘满自动停写，受配置项 log_disk_utilization_limit_threshold 控制，可以暂时调大到 98（可以只指定盘满的节点）。改完之后，落后的副本会立即触发追日志，如果落后很多会触发 rebuild 动作（rebuild 表示直接从 Leader 副本拷贝数据和 clog，而不仅仅是拉取 clog）。

2. 查询内部表确认 rebuild 操作，及 clog 同步的进度。

3. 如果调大 log_disk_utilization_limit_threshold 的方式依然不能缓解 clog 持续写满的问题，还可以将 OBServer 停机后，将 clog 文件拷贝至另一存储空间更大的目录下，并用软链接的方式链接过去。完成操作后重新启动 OBServer。如果 clog 盘的使用降到了 95% 水位以下，说明 OBServer 恢复顺利，继续等待所有副本达到 sync 状态即可。

   注意

   该步骤存在一定的操作风险，是在集群无法恢复时应急操作的最后办法。拷贝日志文件时应避免误操作。

4. 回滚所有的操作及配置项。

常见 CLOG 盘满的原因

• 运维问题

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

• 转储持续失败

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