create tenant 发生timeout

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】
【 使用版本 】5.7.25-OceanBase_CE-v4.3.1.0
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
在我的测试环境create tenant时发生timeout,
1.发布的ceate tenant语法如下：
create tenant obuser primary_zone=‘zone1’, resource_pool_list=(‘obuser_pool’);
2.查询事发的session以及trace_id
select id,user,tenant,state,trace_id from v$ob_session where state=‘active’
返回：
id=3221488449
trace_id=YB42AC136BFB-000623CC0A7BE7D9-0-0
info:create tenant obuser primary_zone=‘zone1’, resource_pool_list=(‘obuser_pool’)
3.根据返回的id,查询wait event:
select sid,event,p1,p2,p3,wait_class,state,wait_time_micro from v$session_wait where sid=3221488449 \G
*************************** 1. row ***************************
sid: 3221488449
event: sync rpc
p1: 518
p2: 491
p3: 0
wait_class: NETWORK
state: WAITED KNOWN TIME
wait_time_micro: 258401
1 row in set (0.003 sec)
4.根据trace_id查询syslog输出：
tail -f ./observer.log|grep “YB42AC136BFB-000623CC0A7BE7D9-0-0”
输出日志截取如下：
[2024-10-06 19:20:05.903005] INFO [RPC.OBMYSQL] print_session_info (ob_sql_nio.cpp:1160) [6970][sql_nio0][T0][Y0-0000000000000000-0-0] [lt=64] [sql nio session](*s={this:0x7dc146ffc030, session_id:3221488449, trace_id:YB42AC136BFB-000623CC0A7BE7D9-0-0, sql_handling_stage:11, sql_initiative_shutdown:false, reader:{fd:167}, err:0, last_decode_time:1728216219286256, pending_write_task:{buf:null, sz:0}, need_epoll_trigger_write:false, consume_size:1508, pending_flag:1, may_handling_flag:true, handler_close_flag:false})
[2024-10-06 19:20:19.286874] WDIAG [RPC] send (ob_poc_rpc_proxy.h:168) [7232][T1_L0_G0][T1][YB42AC136BFB-000623CC0A7BE7D9-0-0] [lt=127][errcode=-4012] sync rpc execute fail(ret=-4012, addr=“172.19.107.251:2882”, pcode=518, timeout=999999721)
[2024-10-06 19:20:19.286919] WDIAG [SQL.ENG] execute (ob_tenant_executor.cpp:94) [7232][T1_L0_G0][T1][YB42AC136BFB-000623CC0A7BE7D9-0-0] [lt=28][errcode=-4012] rpc proxy create tenant failed(ret=-4012)
[2024-10-06 19:20:19.286933] INFO [SQL.ENG] execute (ob_tenant_executor.cpp:107) [7232][T1_L0_G0][T1][YB42AC136BFB-000623CC0A7BE7D9-0-0] [lt=12] [CREATE TENANT] create tenant(ret=-4012, ret=“OB_TIMEOUT”, create_tenant_arg=tenant_schema:{tenant_id:18446744073709551615, schema_version:1, tenant_name:“obuser”, zone_list:[cnt:0], primary_zone:“zone1”, charset_type:2, locked:false, comment:"", name_case_mode:-1, read_only:false, locality_str:"", zone_replica_attr_array:[cnt:0], primary_zone_array:[], previous_locality_str:"", default_tablegroup_id:18446744073709551615, default_tablegroup_name:"", compatibility_mode:-1, drop_tenant_time:-1, status:0, in_recyclebin:false, arbitration_service_status:{status:3}}, pool_list:[“obuser_pool”], if_not_exist:false, sys_var_list:[], name_case_mode:-1, is_restore:false, palf_base_info:{prev_log_info:{log_id:-1, lsn:{lsn:18446744073709551615}, scn:{val:18446744073709551615, v:3}, log_proposal_id:9223372036854775807, accum_checksum:-1}, curr_lsn:{lsn:18446744073709551615}}, recovery_until_scn:{val:0, v:0}, compatible_version:0, is_creating_standby:false, log_restore_source:"", is_tmp_tenant_for_recover:false, source_tenant_id:0, cost=999999522)
[2024-10-06 19:20:19.287063] INFO [SHARE] add_event (ob_event_history_table_operator.h:261) [7232][T1_L0_G0][T1][YB42AC136BFB-000623CC0A7BE7D9-0-0] [lt=52] event table add task(ret=0, event_table_name="_all_server_event_history", sql=INSERT INTO all_server_event_history (gmt_create, module, event, name1, value1, name2, value2, name3, value3, name4, value4, value5, value6, svr_ip, svr_port) VALUES (usec_to_time(1728217219286989), ‘sql’, ‘execute_cmd’, ‘cmd_type’, 8, ‘sql_text’, X’6372656174652074656E616E74206F6275736572207072696D6172795F7A6F6E653D277A6F6E6531272C207265736F757263655F706F6F6C5F6C6973743D28276F62757365725F706F6F6C2729’, ‘return_code’, -4012, ‘tenant_id’, 1, ‘’, ‘’, ‘172.19.107.251’, 2882))
[2024-10-06 19:20:19.287084] WDIAG [SQL] open_cmd (ob_result_set.cpp:102) [7232][T1_L0_G0][T1][YB42AC136BFB-000623CC0A7BE7D9-0-0] [lt=13][errcode=-4012] execute cmd failed(ret=-4012)
[2024-10-06 19:20:19.287096] WDIAG [SQL] open (ob_result_set.cpp:161) [7232][T1_L0_G0][T1][YB42AC136BFB-000623CC0A7BE7D9-0-0] [lt=10][errcode=-4012] execute plan failed(ret=-4012)
[2024-10-06 19:20:19.287111] WDIAG [SERVER] response_result (ob_sync_cmd_driver.cpp:143) [7232][T1_L0_G0][T1][YB42AC136BFB-000623CC0A7BE7D9-0-0] [lt=10][errcode=-4012] close result set fail(cret=-4012)
[2024-10-06 19:20:19.287124] WDIAG [SERVER] after_func (ob_query_retry_ctrl.cpp:986) [7232][T1_L0_G0][T1][YB42AC136BFB-000623CC0A7BE7D9-0-0] [lt=10][errcode=-4012] [RETRY] check if need retry(v={force_local_retry:false, stmt_retry_times:0, local_retry_times:0, err:-4012, err:“OB_TIMEOUT”, retry_type:0, client_ret:-4012}, need_retry=false)
[2024-10-06 19:20:19.287142] WDIAG [SERVER] response_result (ob_sync_cmd_driver.cpp:149) [7232][T1_L0_G0][T1][YB42AC136BFB-000623CC0A7BE7D9-0-0] [lt=17][errcode=-4012] result set open failed, check if need retry(ret=-4012, cli_ret=-4012, retry_ctrl.need_retry()=0)
[2024-10-06 19:20:19.287384] INFO [SERVER] send_error_packet (obmp_packet_sender.cpp:378) [7232][T1_L0_G0][T1][YB42AC136BFB-000623CC0A7BE7D9-0-0] [lt=12] REACH SYSLOG RATE LIMIT [bandwidth]
[2024-10-06 19:20:19.287422] WDIAG [SERVER] do_process (obmp_query.cpp:818) [7232][T1_L0_G0][T1][YB42AC136BFB-000623CC0A7BE7D9-0-0] [lt=17][errcode=-4012] execute query fail(ret=-4012, timeout_timestamp=1728217219287156)
[2024-10-06 19:20:19.287487] WDIAG [SERVER.OMT] process_one (ob_worker_processor.cpp:89) [7232][T1_L0_G0][T1][YB42AC136BFB-000623CC0A7BE7D9-0-0] [lt=12][errcode=-4012] process request fail(ret=-4012)
[2024-10-06 19:20:19.287501] WDIAG [SERVER.OMT] process (ob_worker_processor.cpp:157) [7232][T1_L0_G0][T1][YB42AC136BFB-000623CC0A7BE7D9-0-0] [lt=12][errcode=-4012] process request fail(ret=-4012)
以上日志截取了一部分（太多）
能帮忙分析一下原因吗，谢谢
另外，感觉大概15分钟create tenant语句就返回timeout,顺便问一下这个超时时间由哪个参数控制？

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

#3

根据您的描述，您在创建租户时遇到了超时问题。这可能涉及到事务处理或系统资源分配的问题。不过，通常创建租户这类操作不应该导致超时，除非是在特定条件下如系统负载过高或网络不稳定等情况下可能发生。关于事务超时，ob_trx_timeout 参数控制的是普通事务的超时时间，但对于创建租户这类DDL操作的超时，可能是由其他机制控制的。

为了更准确地定位问题，建议使用 obdiag 工具来收集相关日志信息。这可以帮助我们了解在创建租户时系统状态的具体情况。

日志采集场景: DDL过程中报磁盘空间不足的问题（虽然您的问题不一定与磁盘空间直接相关，但这是最接近的DDL相关问题场景）
日志采集命令: obdiag gather scene run --scene=ddl_disk_full

同时，考虑到创建租户可能涉及长时间的操作，也可以考虑收集长事务的相关信息。

日志采集场景: 长事务
日志采集命令: obdiag gather scene run --scene=observer.long_transaction

请您执行上述命令并将生成的日志文件发送给我们，以便我们进一步分析。

为了更好地帮助您解决问题，请提供以下信息：

  1. 创建租户时是否有任何错误消息或警告？
  2. 您的OceanBase集群当前的负载情况如何？是否有其他大量的并发操作正在进行？
  3. 创建租户操作是在一个全新的集群上尝试的还是在一个已有多个租户的环境中？
  4. 是否可以提供更多关于创建租户时的具体操作步骤或使用的命令？

更多信息请查看:

  1. 事务超时，错误代码 ERROR 4012

附上敏捷诊断工具 obdiag 使用帮助链接

#4

当我run obdiag时，它说invalid task:ddl_disk_full
obadmin@obsrv01:~/oceanbase-diagnostic-tool$ ./obdiag gather scene run --scene=ddl_disk_full
gather_scenes_run start …
gather from_time: 2024-10-06 21:21:38, to_time: 2024-10-06 21:52:38
[ERROR] Invalid Task :ddl_disk_full
同样，当我run observer.long_transaction场景时也获得如下错误，我哪里错了吗
obadmin@obsrv01:~/oceanbase-diagnostic-tool$ ./obdiag gather scene run --scene=o bserver.long_transaction
gather_scenes_run start …
gather from_time: 2024-10-06 21:25:21, to_time: 2024-10-06 21:56:21
[ERROR] Invalid Task :observer.long_transaction

Gather scene results stored in this directory: /home/obadmin/oceanbase-diagnosti c-tool/gather_pack_20241006215521

Trace ID: 026c33d2-83f3-11ef-b924-080027aaab98
If you want to view detailed obdiag logs, please run: obdiag display-trace 026c3 3d2-83f3-11ef-b924-080027aaab98

#5

您的问题可能存在误解，实际上据我所知 obdiag 的场景收集功能可能需要更新到最新版本才能支持某些特定的任务类型，比如 ddl_disk_full 或 observer.long_transaction。您当前遇到的错误提示表明这些场景任务可能并未被识别或支持。

解决方案：

  1. 升级 obdiag 工具：确保您的 obdiag 版本是最新的。您可以重新下载最新版本的 obdiag 并替换现有的工具。通常，OceanBase 官方会定期发布更新版本，修复已知问题并增加新功能。

  2. 手动收集日志：如果暂时无法升级工具，您可以手动收集一些关键日志信息。例如，可以通过查询系统表来获取有关创建租户时的详细信息：

    SELECT * FROM __all_virtual_tenant WHERE tenant_name = 'obuser';

  3. 检查官方文档：访问 OceanBase 的官方文档或社区论坛，查找有关 obdiag 的最新使用指南。确保您正在按照最新的指导进行操作。

  4. 联系技术支持：如果上述方法均未能解决问题，建议联系 OceanBase 的技术支持团队。他们可以提供更详细的指导和支持。

替代方案：

如果您暂时无法通过 obdiag 收集所需信息，可以尝试以下替代方案来诊断问题：

  • 查看系统日志：检查 observer.log 文件中是否有更多关于创建租户时的错误信息。
  • 监控系统性能：使用 top 或 htop 等工具监控服务器的 CPU、内存和磁盘 I/O 使用情况，确保没有异常高的负载。
  • 网络延迟检测：由于您的日志中提到 sync rpc 超时，可以尝试使用 ping 或 traceroute 检测集群内部节点间的网络延迟情况。

希望上述建议能够帮助您解决问题。如果还有其他疑问或需要进一步的帮助，请随时告知。

检索到的文档如下:

  1. 快速入门：obdiag 全链路功能诊断

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#6

确认下创建租户的unit的规格大小，集群规格大小。
事务超时可以根据下面的文档进行设置
https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000217854

#7

你的部署架构是多节点吗？

–查看当前服务器信息

select * from DBA_OB_SERVERS;

–查看各租户资源分配

select t1.name resource_pool_name, t2.`name` unit_config_name, 
t2.max_cpu, t2.min_cpu, 
round(t2.memory_size/1024/1024/1024,2) mem_size_gb,
round(t2.log_disk_size/1024/1024/1024,2) log_disk_size_gb, t2.max_iops, 
t2.min_iops, t3.unit_id, t3.zone, concat(t3.svr_ip,':',t3.`svr_port`) observer,
t4.tenant_id, t4.tenant_name
from __all_resource_pool t1
join __all_unit_config t2 on (t1.unit_config_id=t2.unit_config_id)
join __all_unit t3 on (t1.`resource_pool_id` = t3.`resource_pool_id`)
left join __all_tenant t4 on (t1.tenant_id=t4.tenant_id)
order by t1.`resource_pool_id`, t2.`unit_config_id`, t3.unit_id;

及

SELECT c.TENANT_ID, e.TENANT_NAME, concat(c.NAME, ': ', d.NAME)`pool:conf`,concat(c.UNIT_COUNT, ' unit: ', d.min_cpu, 'C/', ROUND(d.MEMORY_SIZE/1024/1024/1024,0), "G") unit_info FROM DBA_OB_RESOURCE_POOLS c, DBA_OB_UNIT_CONFIGS d, DBA_OB_TENANTS e WHERE c.UNIT_CONFIG_ID=d.UNIT_CONFIG_ID AND c.TENANT_ID=e.TENANT_ID AND c.TENANT_ID>1000 ORDER BY c.TENANT_ID;