背景
建索引可能因各种各样的原因产生报错，本文主要介绍碰到建索引报错时，如何定位到建索引报错的日志，方便后续进一步使用工具一键收集日志/根因分析，分析根本原因。
备注：此文档中涉及的语句适用于版本号>=4.2.3和 >= 4.3的。
问题排查
建索引主要分为几个阶段
- 发送RPC给RS执行建索引的第一步schema变更，并生成调度任务
- RS按照状态机执行调度任务，具体分为如下步骤
-
- 等事务结束
- 数据补全
- 校验checksum
- 索引表生效
- 失败/成功清理
- 建索引的工作线程刷新到RS执行任务完成，返回结果
建索引报错的日志分析的基本思路是根据建索引的基本步骤，判断建索引失败在哪一步，然后决策收集哪些机器的日志，排查的基本步骤如下
- 获取DDL报错表格的名字和租户的名字，可以作为输入参数
- 根据表格名字和租户名字，获取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';- 根据索引名，查询到索引表ID
1. 根据索引名，查询索引表的id
select table_id from __all_virtual_table_history where tenant_id = 'xxx' and data_table_id = 'xxx' and table_name like '%索引名%';- 根据索引表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
- 根据__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
- 如果是在等事务结束阶段失败，也就是event的名字为ddl wait trans end ctx try_wait，那么根据trace_id，去捞主表所有的tablet所在leader节点的日志
- 如果是在补数据阶段失败，那么根据value6字段解析出补数据失败的observer地址，根据observer地址以及trace_id，捞取observer对应的日志
- 如果是其他阶段失败，那么根据trace_id，以及rs_svr_ip和rs_svr_port来捞取执行时主RS的日志
OceanBase敏捷诊断工具相关链接：
| github仓库 | GitHub - oceanbase/oceanbase-diagnostic-tool: OceanBase Diagnostic Tool is designed to help OceanBase users quickly gather necessary information and analyze the cause of the problem. |
| rpm包下载 | OceanBase分布式数据库-海量数据 笔笔算数 |
| 文档链接 | OceanBase分布式数据库-海量数据 笔笔算数 |
