---
title: "日志同步问题 - OceanBase 数据库 V4.2.1 | OceanBase 文档中心"
description: 日志同步问题 本文介绍日志同步的基本原理及常见问题。 OceanBase clog 的全称是 OceanBase Commit Log，是 OceanBase 日志服务的核心。日志服务是 OceanBase 数据库的基础组件，承担着支持事务的原子性、持久性、隔离性以及数据库高可用等核心功能。在数据库提交的过程中通过 …
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 4.2.1 LTS

# 日志同步问题

更新时间：2026-04-16 00:11:35

[编辑](https://github.com/oceanbase/oceanbase-doc/edit/V4.2.1/zh-CN/600.manage/1000.troubleshooting/700.clog.md)  

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

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）。
 - 查询日志模块的访问模式。
 - 其他问题定位需求等。

## 重要配置项

| 配置项名称 | 默认值 | 说明 | 生效范围 | 生效时机 |
| --- | --- | --- | --- | --- |
| `log_disk_utilization_threshold` | 80 | 租户分配的日志盘空间不会全部使用，而是只使用一定阈值内的空间。在超过设定阈值后，会将可以回收的日志文件回收掉。该配置项控制此阈值。 | 租户级 | 立即生效 |
| `log_disk_utilization_limit_threshold` | 95 | 在系统写入量大等场景下，由于 checkpoint 不及时，最早的日志文件不允许回收。因此日志盘实际使用的空间允许短暂超过 `log_disk_utilization_threshold` 配置的值，但仍存在一个上限。该上限值由 `log_disk_utilization_limit_threshold` 控制。超过此上限，日志盘会拒绝新的写入。此时需要运维人员介入处理。 | 租户级 | 立即生效 |

## clog 盘满

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

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

### 排查步骤

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

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

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

   ```shell
   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 语句为：

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

   ```

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

   ```shell
   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. 确认冻结是否存在问题。

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

        ```shell
        # 系统冻结开始
        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 技术支持进行介入诊断。

 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线