---
title: 删租户卡住如何排查-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于 删租户卡住如何排查相关的常见问题和使用技巧，帮助您快速解决 删租户卡住如何排查的难题。
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

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

划线反馈

# 删租户卡住如何排查

更新时间：2024-06-14 05:56

适用版本： V4.0.x、V4.1.x、V4.2.x 内容类型：How-to  

Drop Tenant 的表现形式如下：

- 回收站打开回收站，租户状态不变。
 - 回收站关闭时：

     - 备库上执行相当于 `drop_tenant force` 。
     - 主库上执行会走安全退出，安全退出的含义是：先标记 `schema` 中的 `dropping` 状态，然后等待用户租户下的所有日志流 GC 完成后，再删除 `schema`。
 - `drop_tenant force`：直接从 schema 中删除。

## 适用版本

OceanBase 数据库 V4.X 版本。

## 排查步骤

在遇到删租户卡住的时候需要按照以下顺序排查。

1. 确定 schema 状态。

   查询 `__all_tenant` 表中关于这个租户的 status 状态。

      1. 租户不存在，查询 `__all_tenant_history` 表关于这个租户 `id` 的最新一条记录是不是 `is_delete` 等于 1，如果是，租户已经删除完成，并没有卡住。
      2. `status` 为 `normal`：则这个命令都没有在 RS 上执行成功，可能有以下情况： a. RS 不存在：去看 1 租户的 1 号日志流是否有 Leader，RS 是否上任成功。

        b. RS 的 DDL 队列积压：去看 `DDLQueueTh0` 线程在做什么。
      3. `status` 为 `dropping`：这个状态是正常的。
 2. 确定日志流状态。

   在系统租户下查询 `__all_virtual_ls_status` 表。

      1. 首先看系统日志流的状态:

        a. `PRE_TENANT_DROPPING`: 在这个状态是在等其他用户日志流 GC，需要看其他用户日志流为什么不 GC，转到 <3> 继续排查。

        b. `TENANT_DROPPING`: 这个状态是说明日志流已经删除完成，但是系统日志流还没有判定可以 GC，转到 <4> 继续排查。

        c. `WAIT_OFFLINE`: 在等系统日志流 GC，转 <5> 继续排查 。
      2. 系统日志流为 `PRE_TENANT_DROPPING`，排查租户下 `__all_ls` 表和对应 meta 租户下 `__all_ls_status` 表的 `status` 是否有差异，也可以在系统租户下直接查询虚拟表 `__all_virtual_ls/__all_virtual_ls_status` 表。

        a. 每个日志流在这两张表上的 `status` 都是一致，没有异常。

        b. `status` 表不一致，需要排查 `T1xxx_PLSSer` 这个线程在做什么。
      3. 以某一个用户日志流为例，排查这个日志流的状态。

        a. `NORMAL`：可能在等用户日志流的 `sync_scn` 越过系统日志流的 `sync_scn`，排查 `__all_tenant_info` 表汇报是否正常，需要排查 `T1xxx_TeRec` 线程是否有回报失败的记录，或者如果每个日志流都汇报到了最新，是否存在无主的日志流。

        b. `TENANT_DROPPING`: 在等底层事务结束，可以排查 `T1xxx_PLSSer` 这个线程，转到 <4> 继续排查。

        c. `WAIT_OFFLINE`: 这个状态需要等底层 GC，转到 <5> 继续排查。

        d. `CREATING/CREATED`：这个状态不应该存在，排查 `T1xxx_PLSSer` 这个线程。
      4. 日志流卡在 `TENANT_DROPPING` 状态。 在这个状态需要等 `T1xxx_PLSSer` 线程发rpc给日志流的leader询问是否可以 GC，所以需要先去看 `T1xxx_PLSSer` 有没有发rpc给日志流的 leader。如果发送了，就拿着 trace 去日志流的 leader 所在的机器上寻找为什么不能 GC 。

             - `T1xxx_PLSSer` 线程关键字：

              ```shell
              LOG_INFO("[PRIMARY_LS_SERVICE] finish to try delete LS", KR(ret), K(status_info), K(cost), K(can_offline));

              ```
             - `GC` 模块关键字：

              ```shell
              check_ls_can_offline

              ```
      5. 日志流状态卡在 `WAITOFFLINE` 状态 这个状态下，日志流已经可以 GC ，只需要等待写 offline 日志，并且真正的删除。日志流在这个状态的残留全都是 GC 模块的问题了。可以去日志流 leader 所在的机器上搜 `T1xxx_GCCollec` 这个线程上是否有对应日志流的 WDIAG 日志。

Previous

[参数 max_syslog_file_time 与 max_syslog_file_count 的关系](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000004752359)

Next

[OceanBase 数据库副本管理原理](https://www.oceanbase.com/knowledge-base/oceanbase-database-20000000065) ![有帮助](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) 咨询热线