【OceanBase诊断调优 】—— 建索引执行报错问题排查

背景

建索引可能因各种各样的原因产生报错，本文主要介绍碰到建索引报错时，如何定位到建索引报错的日志，方便后续进一步使用工具一键收集日志/根因分析，分析根本原因。

备注：此文档中涉及的语句适用于版本号>=4.2.3和 >= 4.3的。

问题排查

建索引主要分为几个阶段

1. 发送RPC给RS执行建索引的第一步schema变更，并生成调度任务
2. RS按照状态机执行调度任务，具体分为如下步骤

1. 1. 等事务结束
   2. 数据补全
   3. 校验checksum
   4. 索引表生效
   5. 失败/成功清理

1. 建索引的工作线程刷新到RS执行任务完成，返回结果

建索引报错的日志分析的基本思路是根据建索引的基本步骤，判断建索引失败在哪一步，然后决策收集哪些机器的日志，排查的基本步骤如下

1. 获取DDL报错表格的名字和租户的名字，可以作为输入参数
2. 根据表格名字和租户名字，获取table_id，tenant_id

select tenant_id from __all_tenant where tenant_name = '租户名';
select table_id from __all_virtual_table where table_name = '表名' and tenant_id = '租户id';

1. 根据索引名，查询到索引表ID

1. 根据索引名，查询索引表的id
select table_id from __all_virtual_table_history where tenant_id = 'xxx' and data_table_id = 'xxx' and table_name like '%索引名%';

1. 根据索引表ID，查询__all_virtual_ddl_error_message表格中是否有记录(select task_id from __all_virtual_ddl_error_message where tenant_id = 'xxxx' and object_id = 'xxxx')，如果无记录，那说明失败在发送RPC，打印出信息，提示此时需要人工接入排查（这里后续梳理出需要添加的信息方便排查问题），否则进入步骤5
2. 根据__all_virtual_ddl_error_message中查询到的task_id字段，查询__all_rootservice_event_history表(select event, trace_id,value6,rs_svr_ip, rs_svr_port from __all_rootservice_event_history where tenant_id = xxxx and value4 = 'task_id' and value2 != 0 and event != 'switch_state' and event not like 'index build task process fail' order by gmt_create desc limit 1;)，根据失败所在的步骤，决策收集的信息，如果event字段的值为是ddl wait trans end ctx try_wait，那么进入步骤6，如果是 index sstable build task finish，那么进入步骤7，如果是其他的步骤，那么进入步骤8
3. 如果是在等事务结束阶段失败，也就是event的名字为ddl wait trans end ctx try_wait，那么根据trace_id，去捞主表所有的tablet所在leader节点的日志
4. 如果是在补数据阶段失败，那么根据value6字段解析出补数据失败的observer地址，根据observer地址以及trace_id，捞取observer对应的日志
5. 如果是其他阶段失败，那么根据trace_id，以及rs_svr_ip和rs_svr_port来捞取执行时主RS的日志

OceanBase敏捷诊断工具相关链接：