删租户卡住如何排查

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 线程关键字：

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

      • GC 模块关键字：

        check_ls_can_offline
        

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