创建租户失败后，执行升级脚本 upgrade_checker.py 报错 compatible is not sync 的原因和解决方法

问题现象

1. 用户创建租户失败/备份恢复租户失败。

2. 执行升级，报错 compatible is not sync。

3. 查询 GV$OB_PARAMETERS 或 __all_virtual_tenant_parameter_stat 表发现有部分租户的 compatible 配置项值为 0.0.0.0。

4. 查询 __all_tenant_history 表，无法搜到这些租户的 tenant_id。

关键诊断信息

触发条件

创建租户失败，并且 __all_tenant_history 没有尝试创建的那个租户的 tenant_id。

事前巡检

升级前检查一下 __all_virtual_tenant_parameter_stat 表里是否有 compatible 值为 0.0.0.0。如果持续出现未知的 tenant_id，并且 tenant_id 大小在增长，则排查一下是否有创建租户重试的操作。

事后诊断

通过 SQL 语句 select * from __all_sys_stat where name='ob_max_used_tenant_id'; 查到 max_tenant_id 被推高了，或者 max_tenant_id 对应的值在 __all_tenant_history 表里也没有。但是 __all_virtual_tenant_parameter_stat 里有这个 tenant_id。

问题原因

在创建租户流程中，第一个事务会写 __all_tenant 及其 history 表，在第一个事务结束前会向租户的各个机器发 RPC 初始化该租户的配置项信息。当这一步报错，或者后续事务提交失败时，各个机器上可能会有配置项信息，但是 __all_tenant_history 表里不会有数据。除了 __all_virtual_tenant_parameter_stat 表，其他地方也不会看到该 tenant_id。 此时立即开始升级流程，因为升级会检查所有租户的 compatible，因此会查询 __all_virtual_tenant_parameter_stat，此时发现有租户 compatible 为 0.0.0.0，就报错。

__all_virtual_tenant_parameter_stat 表会查询 ObTenantMgr 里的各个租户的配置项信息，这里的内容清理条件如下。

1. 租户在 schema 中被标记为 dropped。

   a. 在本问题中因为租户并没有插入 __all_tenant_history 表，所以无法标记为 dropped。

2. 本机上没有租户资源超过 30 分钟。

   a. 因为创建租户时会存在当前机器不存在租户 Unit，但是 config 存在的情况。因此在这 30 分钟内执行升级脚本会报错。

问题的风险及影响

升级推迟 30 分钟，用户不断重试创建租户可能会导致 ob_max_used_tenant_id 被推高。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

影响版本

OceanBase 数据库企业版 V4.1.0（oceanbase-4.1.0.0-100001122023040322）及之后版本、V4.2.0 GA（oceanbase-4.2.0.0-100010082023083014）及之后版本、V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本、V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）及之后版本、V4.3.0（oceanbase-4.3.0.0-100000072024020200）及之后版本。

解决方法及规避方式

• 解决方法：

  等待 30 分钟，或者手动修改升级脚本，删除报错部分的内容。

• 规避方式：

  对创建租户的行为进行限制，创建租户失败并且 __all_tenant_history 表中查不到新租户时不要盲目重试，准备升级前尽量不要创建/恢复租户。