OBServer 重启后，建已存在表耗时 30s

问题现象

create table if not exists 在表已存在的情况下耗时 30s，且发起端可以看到 OBServer 日志打印 schema version not sync。

关键诊断信息

触发条件

1. 发起 DDL 请求的 OBServer 重启后没有执行过任何一条并行 DDL。

2. 并行 DDL 配置项 _enable_parallel_table_creation 为 true。

3. 用 create table if not exists 语句建已存在表。

事前巡检

重启后有没有执行过一条有效的并行 DDL 比如建表。

事后诊断

建表耗时 30s，发起端 OBServer 日志可以看到 schema version not sync 且 consensus_schema_version 为 0。

问题原因

1. 串行 DDL 在执行完成之后会主动触发一次 schema 刷新，在并行 DDL 的场景这种操作是非常影响吞吐的。因此并行 DDL 在执行完成之后会在后台批量广播 schema，每次生成一个 consensus schema version。此字端没有持久化，因此在 OBServer 重启的时候，这个字端为 0，直到下一次并行 DDL 触发后台刷 schema 的任务。

2. create table if not exists 在 table 存在的情况下是 do nothing 的语义，此时实际上没有 DDL 发生，因此不会生成新的 schema，也不会触发后台广播 schema 的逻辑。

3. 在 OBServer 重启之后，consensus_schema_version 为 0。没有并行 DDL 的情况下，RS 不会去广播推 consensus_schema_version。此时执行 create table if not exists，在表已存在的情况下，RS 会返回这个存在表的最新的 schema_version，DDL 发起端需要等到 consensus_schema_version 大于这个 schema_version，此处最多等 30s。

4. 总体来说并行 DDL 框架下，新的 schema 广播方式在 create table if not exits 这个场景的一个 bad case。

问题的风险及影响

在此场景下，每一条 create table if not exits 都会占住发起端 OBServer 工作线程 30s。并发量越大，对集群的整体影响越大。如果是一个很大的可以把租户工作线程都占满的并发量，那么在这 30s 期间租户的流量可能会跌零。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 MySQL 租户，对于 Oracle 租户无影响。

影响版本

OceanBase 数据库企业版 V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本、V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）及之后版本。

解决方法

• 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.2.1 BP4 Hotfix2（oceanbase-4.2.1.4-104020022024031915）及之后版本、V4.2.1 BP4 Hotfix（oceanbase-4.2.1.4-104030022024032913）及之后版本、V4.2.1 BP5（oceanbase-4.2.1.5-105000072024041817）及之后版本、V4.2.3（oceanbase-4.2.3.0-100000052024041220）及之后版本。

• 主动触发一次有效的并行 DDL 如 create table 或 truncate table。

规避方式

OBServer 重启后主动触发一次有效的并行 DDL 如 create table 或 truncate table。