数据库学习Q&A 045：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 层，网络层（基础设施层）的瓶颈，也可以少数派节点上，执行下面的操作：

1. Clog 盘达到 95% 之后自动停写，无法再接收日志，这个阈值是 OceanBase 数据库的一个配置项控制的，我们可以首先调大它到 98，可以指定只修改盘满的 Server：

   alter system set clog_disk_usage_limit_percentage = 98 server ='xxx:2882';
   

   改完之后，落后的副本会立即触发追日志，如果落后很多会触发 rebuild（从 Leader 拷贝 data+Clog ），可以通过如下方式观察恢复过程。

2. 执行如下 sql 检查 Clog 不同步的分区数是否有减少：

   select svr_ip, count(*) from  gv$ob_log_stat  where is_offline = 0 and is_in_sync = 0 group by 1;    
   

   如果没有快速减少，可能有副本触发了 rebuild（rebuild 是一种落后太多情况下追赶的方式，会拷贝基线+增量），继续执行如下 sql 查询是否有正在做 rebuild 的副本：

   select svr_ip, count(*) from __all_virtual_partition_migration_status  where action != 'END' group by 1;
   

   若上述查询结果非 0，则继续检查 rebuild 任务并发相关的配置项：

   show parameters like "%data_copy%";
   

   如果 server_data_copy_in_concurrency、server_data_copy_out_concurrency都还是默认值 2，那么将二者均调整为 10，加快多个副本 rebuild 的并发：

   alter system set server_data_copy_in_concurrency = 10;
   alter system set server_data_copy_out_concurrency = 10;
   

3. 如果通过调大 Clog_disk_usage_limit_percentage 至 98% 的方式仍然不能缓解 Clog 持续写满的问题，还可以将 OBServer 节点停机后，将 Clog 文件拷贝到另一个存储空间更大的目录下，并将 Clog 用软链接的方式链接过去。在完成后重新启动 OBServer。

   注意

   请注意该步骤存在一定的操作风险，是在集群无法使用后应急操作恢复系统可用的最后办法。请在拷贝日志文件时格外注意，避免操作错误 。

   如果 Clog 的使用降到了 95% 水位以下，说明 OBServer 节点恢复顺利。继续等待所有副本达到 sync 状态即可。

4. is_in_sync= 0 的副本数量降为 0 之后，将上述所有改过的配置项恢复原值。

可能原因

• 运维问题。 Clog 盘所在空间被其他用户的文件占用，导致可以利用的空间不足。
• 转储持续失败是 Clog 满盘最常见的原因。 当 Clog 中涉及的分区数据已经全部转储到 SSTable 中，且 partition 的元信息已经持久化宕机重启起始位点时， Clog 文件就可以进行回收。所以，如果转储不成功，宕机重启 Clog 起始回放位点不推进，CLOG 文件是无法进行回收的。因转储持续失败的原因场景和具体原因逻辑相较比较复杂，遇到该种情景，请联系 OceanBase 数据库技术支持进行介入诊断。