在 OCP 管控的 OBServer 集群中收到 clog disk is almost full 的告警。observer.log 中报错 clog disk is almost full。该告警和报错不可忽略，需要运维操作保证 clog 不至于达到 clog_disk_usage_limit_percentage （默认值 95%）进而导致 clog 无法写入，事务无法提交的严重影响。
本文档介绍该场景下可采取的应急措施。
可能原因
运维问题
Clog 盘所在空间被其他用户的文件占用，导致可以利用的空间不足。请保证 Clog 所在的目录空间没有其他文件进行存放导致 Clog 反而不能写入的极端故障情况。
转储持续失败
转储持续失败是 Clog 满盘最常见的原因，当 Clog 中涉及的分区数据已经全部转储到 SSTable 中，且 partition 的元信息已经持久化宕机重启起始位点时，Clog 文件就可以进行回收。所以，如果转储不成功，宕机重启 Clog 起始回放位点不推进，Clog 文件是无法进行回收的。
在 OBServer V2.x 以及之前版本，为了方便解释，将转储过程分为三个阶段：转储前、转储中和转储后。其中，各个阶段需要完成的工作如下：转储前：冻结成功、转储成功调度；转储中：转储线程读取 memtable 中目标数据，并将其 dump 到磁盘；转储后：汇报转储信息到内部表、分区 Meta 内存数据结构，释放 frozen memstore 的内存。在各个阶段中可能会出现的导致转储失败的原因有：
转储阶段 转储不成功的原因 影响和排查手段 转储前 schema 被 drop 的分区不参与转储 schema 不存在的分区不参与转储，依赖 GC 进行删除，一旦 GC 线程异常，该分区本机的 CLOG 日志无法进行回收。 转储前 转储调度依赖转储位点之前的事务都已经结束 一旦某个转储位点之前的事务异常，持续不结束，转储无法调度，存在 CLOG 盘爆的风险。这类问题是导致 CLOG 盘爆的高频原因事务异常场景较多，抽象概括起来，主要包括：
- 无主：事务涉及到的参与者只要有任何一个无主，都会影响事务的推进。
- 内存爆：内存爆问题严重程度仅次于无主，爆掉的机器，无法接受新的日志，影响事务执行、提交。
- XA：XA 事务 prepare 之后，没有收到客户端发来的 commit 或者 rollback 命令，导致事务悬挂。
- IO 异常：比如 IO hang 住，备机无法接受日志，事务状态无法回放，备机事务结束不了，转储卡住。
- 落后副本 rebuild 失败：目前对于现有的各个版本，备机数据落后之后，触发 rebuild 由于源端数据落后，rebuild 失败，之后的重试逻辑没有切换源端的机制。导致副本数据持续落后，转储卡住，clog 盘爆。
转储中 转储动作正常进行，但能力有限。 - 转储跟不上写入，大概率导致内存爆，进而影响 CLOG 日志回收。
- 内外部业务多次出现转储线程卡住，导致内存爆，进而 clog 盘爆。
- 备机内存规格小于 leader。
转储后 转储之后释放 frozen memstore 需要依赖 schema 释放 fronzen memstore 过程中，需要确保分区的所有 table store 都已经转储完成，这里包括主表和索引表。索引表的 check 需要依赖 schema 的信息，如果此时本地没有获取到 schema，这里的检查会持续失败。最终导致转储后 frozen memstore 无法释放，分区 Meta 上宕机重启起始位点无法推进。 在 OBServer V3.x 上，OceanBase 提高了对大事务场景的支持，能够做到转储未提交事务。理论上由于转储持续失败导致 clog 不停增长直至满盘的极端情况会有大幅改善。
- OBServer 事务一阶段 CLOG 的优化导致 Clog 回收依赖全局位点，在生产环境中我们不推荐打开事务一阶段优化。
- 日志副本副本 Clog 回收位点需要依赖成员列表中多数派全能型副本已经确认的 LogID。这样的特性意味着如果存在全能型副本和日志副本混布的情况，如果全能型副本出现无主的情况，日志副本如果持续有 Clog 写入，有可能会导致会 Clog 无法回收爆盘的情况。在生产环境中不建议混部（混合部署）全能型副本和日志副本。
应急操作
Clog 空间问题会导致 OBServer 停写，进而影响到业务服务。在出现该故障场景时，可以参考以下方式及时处理空间问题，保证业务快速恢复服务。
确认 OceanBase 集群状态，如，集群登录失败、observer inactive 等。
确认 Clog 目录空间的使用情况，通过
observer.log日志报错以及磁盘实际使用情况来共同确定。- 确认
observer.log，Clog disk 空间报错信息，使用率超过设置阀值，如 95%。
grep 'clog disk is almost full' observer.log- 确认 OBServer Clog 目录使用情况，查看 Clog 目录下是全是由于 Clog 占满，如果是运维错误操作导致 Clog 目录下有大量其他文件占用，请合理维护和清理确保 Clog 目录下的空间由 Clog 占用。如果确实是 Clog 的占用已经接近了 Clog disk 空间阈值 95%，需要进一步通过下面的步骤缓解 Clog 使用情况。
df -h /data/log1- 确认
如果 OBServer 集群可以登录，临时调整 Clog 的可用空间阀值。
- 登录 sys 租户，增加 Clog 可用百分比（i.e. clog_disk_usage_limit_percentage），如 95 到 98。
alter system set clog_disk_usage_limit_percentage=98;- 如果上述方法未能缓解大量的 Clog 增长问题，在 observer 进程运行过程中，移走 Clog 文件，保证 clog 目录使用空间低于阀值，操作 clog 挪动作需要联系 OceanBase 技术支持处理。
mv /data/log1//clog/<最老的clog文件> <临时保存 clog 文件目录>如果 OBServer 集群无法登录，通过以下方式临时调整 Clog 的可用空间阀值。
- 增加 Clog 可用百分比，如 95 到 98
(admin) /home/admin/oceanbase/bin/ob_admin -h 'ip' -p 2882 set_server_config clog_disk_usage_limit_percentage=98- 如果上述方法未能缓解大量的 Clog 增长问题，在 OBServer 进程运行过程中，移走 Clog 文件，保证 Clog 目录使用空间低于阀值，操作 clog 挪动作需要联系 OceanBase 技术支持处理。
mv /data/log1//clog/<最老的 clog 文件> <临时保存 clog 文件目录>如果 observer 进程已经结束
- 手动拉起 OBServer，启动参数设置 Clog 可用百分比 98。
(admin) /home/admin/oceanbase/bin/observer -o clog_disk_usage_limit_percentage=98- 等待 observer 启动提供服务之后，如果仍未能缓解大量的 Clog 空间增长问题，在 OBServer 进程运行过程中，移走 Clog 文件，保证 clog 目录使用空间低于阀值 ，操作 clog 挪动作需要联系 OceanBase 技术支持处理。
mv /data/log1//clog/<最老的 clog 文件> <临时保存 clog 文件目录>观察 OBServer 状态直到自动恢复。
保存
observer.log联系 OceanBase 技术支持检查 Clog 清理问题。
适用版本
OceanBase 数据库 V2.x、V3.x 版本。
