[Bug]: Creating a tenant has not been successful

[tianyahui-python]

Is there an existing issue for the same bug?

• [X] I have checked the existing issues.

Environment

- Version or commit-id (e.g. v0.1.0 or 8b23a93):
- Hardware parameters:
- OS type:
- Others:

Actual Behavior

link issue: https://github.com/matrixorigin/MO-Cloud/issues/1935

Expected Behavior

No response

Steps to Reproduce

No response

Additional information

No response

[sukki37]

[qingxinhome]

[qingxinhome]

mysql> select transaction_id, request_at, statement, status, error from statement_info where request_at > '2023-12-05 06:00:00' and request_at < '2023-12-05 07:28:00' and statement like '%CREATE ACCOUNT IF NOT EXISTS 3a4bf5d7_46e6_4e77_aca3_c5cd15be2071%';

假设1： 第一行记录虽然失败，但是create account实际成功了 但是，在数据响应给客户端时，发生 "broken pipe" 错误。 此时该租户实际上创建成功，元数据信息完整。后续再次创建同名租户时，就报唯一索引冲突了 讲不通的地方： 1.中间没有drop account，但是最后CREATE ACCOUNT IF NOT EXISTS语句一条却成功了 2.用户中间多次采用的是CREATE ACCOUNT IF NOT EXISTS执行，理应都成功才对

注："broken pipe" 错误通常表示在你的 Go 程序中，尝试写入到已经关闭的管道（pipe）时发生了错误。 这可能是因为你的程序中的某个部分试图向一个已经关闭的管道写入数据。

假设2： 第一行记录 create account失败了，事务回滚，但是mo_account表的唯一索引对应的索引表没有成功回滚，导致其残留在索引表中一条记录，后期 执行CREATE ACCOUNT IF NOT EXISTS时，往mo_account表中插入数据，发生唯一索引冲突， 讲不通的地方：

1. 如果是这样，那么会导致一只创建失败，永远不会成功，除非手动删除索引表中非法的记录
2. 第一行记录报的错误信息是怎么回事？ routine send response failed. error:write tcp4 172.20.2.131:6001->172.20.1.137:48856: write: broken pipe

[qingxinhome]

问题原因详述：

1. 第一条记录的CREATE ACCOUNT IF NOT EXISTS 3a4bf5d7_46e6_4e77_aca3_c5cd15be2071 语句 实际上是执行成功的，但是它的执行时间过长(这个地方是有问题) 执行时长大约为40分钟，开始时间为request_at = 2023-12-05 06:47:16.097800 结束时将为response_at = 2023-12-05 07:26:40.466321， 由于时间过长，应用层提前关闭该session，导致response时无法将响应结果写入，于是第一条CREATE ACCOUNT语句报错 "broken pipe"

2. CREATE ACCOUNT 语句在执行过程中是通过一个后台session，开启一个显式事务 begin ... commit;方式来初始化新租户的系统资源 包括: mo_account表中插入数据，创建新的数据库，创建表和视图等SQL,其中 insert into mo_catalog.mo_account( account_name, status, created_time, comments) values ("bd319655_9a66_4116_a19f_837f7145cd3c","open","2023-12-05 06:39:07","") 是执行是成功的，会把一条新创建租户信息插入mo_account表（包含唯一索引）中，它也是在显式事务执行的， 此时，该条记录会上锁，在事务提交前，其他CREATE ACCOUNT语句不可读，后续的CREATE ACCOUNT IF NOT EXISTS 3a4bf5d7_46e6_4e77_aca3_c5cd15be2071语句均以： Duplicate entry '3a4bf5d7_46e6_4e77_aca3_c5cd15be2071' for key 'mo_index_idx_col' 方式失败， 且这些语句的相应时间都是 在2023-12-05 07:26:40.466321之后， 原因是他们都在排队等待的 mo_account表锁，在时间023-12-05 07:26:40.466321后，第一条create account语句成功执行，且事务提交，mo_account表锁释放，后续的create account获取 mo_account表锁后执行 insert into mo_catalog.mo_account 语句，但是租户3a4bf5d7_46e6_4e77_aca3_c5cd15be2071 已经存在，于是报了 Duplicate entry '3a4bf5d7_46e6_4e77_aca3_c5cd15be2071' for key 'mo_index_idx_col' 的错误

3. 为什么最后一条CREATE ACCOUNT IF NOT EXISTS 3a4bf5d7_46e6_4e77_aca3_c5cd15be2071语句 执行成功？ 原因最后一条CREATE ACCOUNT语句的request_at =2023-12-05 07:27:01.440736，而 此时第一条CREATE ACCOUNT IF NOT EXISTS 3a4bf5d7_46e6_4e77_aca3_c5cd15be2071语句已经成功执行且事务提交， 由于是包含IF NOT EXISTS，系统检查到租户已存在，直接返回成功

4. 第一条记录的CREATE ACCOUNT IF NOT EXISTS 3a4bf5d7_46e6_4e77_aca3_c5cd15be2071 语句长时间执行的原因： 经过定位发现，第一条CREATE ACCOUNT在执行初始化操作时，执行的一系列的SQL，其中在执行如下语句： statement: create table mo_indexes( id bigint unsigned not null, table_id bigint unsigned not null, database_id bigint unsigned not null, name varchar(64) not null, type varchar(11) not null, is_visible tinyint not null, hidden tinyint not null, comment varchar(2048) not null, column_name varchar(256) not null, ordinal_position int unsigned not null, options text, index_table_name varchar(5000), primary key(id, column_name) )； 执行时间过程，大约就是40分钟，其开始时间和结束时间如下 request_at: 2023-12-05 06:47:16.127431 response_at: 2023-12-05 07:26:40.128010 正好对应了第一条CREATE ACCOUNT语句的执行周期，经过分析认为他可能在长时间等待锁，而且在这条SQL之前，也有SQL执行在长时间等待 @fengttt @sukki37 @ouyuanning @daviszhen @zhangxu19830126 @tianyahui-python @aylei @xzxiong

[qingxinhome]

[qingxinhome]

Testing in progress, currently not replicated

[qingxinhome]

Testing in progress, currently not replicated

[qingxinhome]

Testing in progres

[daviszhen]

跟 #13944 同一个问题。pr中

[daviszhen]

已经解决

[tianyahui-python]

待测试