如何分析OceanBase在DDL过程中的报错场景？| 中国联通+OceanBase技术合作解析

在2021年底，中国联通软件研究院（简称联通软研院）经过深思熟虑和广泛调研后，决定采用OceanBase社区版来开发其自主研发的分布式数据库产品——CUDB（China Unicom Database，即中国联通数据库）。截至目前，CUDB已成功应用于中国联通超过338个项目，助力应用迁移数据量达到85TB，实现了慢SQL数量减少43%，并使得数据库运维效率每人平均提升20%。

为了进一步提升产品功能，满足中国联通独特的业务需求，联通软研院与OceanBase社区在数据库内核及其外围工具方面展开了密切合作。这包括了对事务日志解析工具LogMiner和敏捷诊断工具obdiag等功能的深入共建，同时也研发了多个核心功能并修复了OceanBase内核中的多个BUG。此前，双方关于LogMiner共建的经验已经通过文章进行了分享，而本文将重点介绍obdiag共建的技术背景、设计理念、实现细节以及它所带来的积极影响。

一、分布式CUDB演进历程

四年前，中国联通基于内部数据库系统的痛点与外部 100% 自研要求的背景，启动全栈分布式数据库建设。从替代高危 MySQL、降低商用依赖，以及提升中国联通软研院软实力等多方面考虑，选定基于国内开源分布式数据库产品 OceanBase 打造自研数据库产品分布式 CUDB（*详情见生产系统稳定上线 600 天 ——中国联通分布式 CUDB 的开源共建和规模化应用）。

对于分布式 CUDB 的演进历程，简言之，联通软研院在引进 OceanBase 的第一年着重于产品化建设。实现产品的一键开通、弹性扩缩、高效迁移，并且开始试点推广应用。2023 年开始对接监控运维体系，并且开始大规模推广使用。重点聚焦数据库产品生态工具方面的补齐和人员能力的提升，为替代 MySQL 和新上应用提供全栈国产的数据库资源及服务能力。

虽然联通软研院做了很多产品能力建设，如高效的数据迁移、异地容灾高可用、完善的数据库自治服务、智能预测与诊断自愈，形成了相对完善的产品体系。但仍面临诸多挑战，比如现有功能不完全满足联通的个性化需求，再比如运维人员对数据库内核和源码的掌控不足，导致处理集群问题时非常棘手。

因此，在 2024 年，联通软研院推动智能化运维，着手智能运维建设。其中，为进一步提高自动化运维诊断效率，联通软研院与OceanBase携手合作，在 OceanBase 敏捷诊断工具 obdiag 的基础上进行深度共建，并深入内核研究，共同研发了一项全新的功能——建索引报错的根因分析功能。

二、敏捷诊断工具obdiag共建背景

OceanBase 是原生分布式数据库系统，故障根因涉及的因素可能有很多，如机器环境、配置参数、运行负载等。专家在排查问题的时候需要获取大量的信息来分析故障。

那么，如何高效地获取故障场景下分散在各个节点的信息，挖掘其中的关联性，帮助用户自助诊断问题呢？

在引入 obdiag 前，每当遇到 OceanBase 数据库系统的复杂故障时，用户往往需要求助于原厂的专业团队，因为故障排查涉及大量分布在不同节点上的信息，收集和整理这些信息缺乏统一工具。

拥有 obdiag 这一敏捷诊断工具后，通过 obdiag 的一键集群巡检、一键诊断分析、一键信息收集及一键根因分析功能，大大简化了故障排查的交互过程。即便是经验相对不足的技术人员也能够快速地识别出潜在问题，并根据诊断结果采取相应的措施，提升了故障排查工作的效率。

然而，obdiag 现有的功能并不能满足联通软研院的故障排查需求。众所周知，在数据库运维中，DDL（Data Definition Language）操作是常见且重要的组成部分，其中包括创建、删除或修改数据库对象，比如表、索引等。但在实际生产环境中，DDL 操作可能会因为各种原因失败，比如资源不足、并发冲突等，这会给业务带来不必要的中断和损失。为了解决这个问题，联通软研院基于 obdiag 框架进行了扩展，设计并实现了新的根因分析功能——建索引报错的根因分析。该功能能够在建索引失败时，像专家一样分析建索引失败的原因，给出分析报告。

三、建索引报错的根因分析

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

排查共 8 个步骤：

第 1 步：租户名、数据库名、表名、创建索引失败的索引名字，作为输入参数。

第2步：根据入参，获取对应的tenant_id、database_id、table_id。

# 获取租户id select tenant_id from __all_tenant where tenant_name = '租户名'; # 获取数据库id select database_id from  __all_database  where database_name='数据库名'; # 获取表id select table_id  from __all_virtual_table where table_name = '表名' and tenant_id = '租户id' and database_id='数据库id';

第 3 步：根据索引名，获取索引表 id。

# 获取索引表id select table_id from __all_virtual_table_history where tenant_id = '租户id' and data_table_id = '数据库id' and table_name like '%索引名%';

第 4 步：根据索引表 ID，查询__all_virtual_ddl_error_message 表格中是否有记录。

# 获取task_id、trace_id select task_id ,trace_id from __all_virtual_ddl_error_message where tenant_id = '租户id' and object_id = '索引表id';

如果无记录，那说明失败在发送 RPC，打印出信息，提示此时需要人工接入排查，否则进入步骤 5。

第 5 步：根据 task_id,查询__all_rootservice_event_history 表。

# 查询__all_rootservice_event_history表 select event, value6,rs_svr_ip, rs_svr_port from __all_rootservice_event_history where 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 步。

第 6 步：event 的名字为 ddl wait trans end ctx try_wait，那么根据 trace_id，去捞主表所有的 tablet 所在 leader 节点的日志。

第 7 步：event 的名字为 index sstable build task finish，根据 trace_id 去捞取observer 的日志。

第 8 步：event 既不是 ddl wait trans end ctx try_wait，也不是 index sstable build task finish，此时需要根据 trace_id 去捞取 rootservice.log.。

目前 obdiag 支持了增加索引时报错诊断场景，该支持适用于 OceanBase 4.2.3  版本及 OceanBase 4.3 版本以上。

obdiag rca run --scene=index_ddl_error --input_parameters='{"tenant_name":"cudb_test","table_name":"test1245","database_name":"test","index_name":"idx_name"}' -c obce423config.yml

input_patameters 是一个用于输入不同根因分析场景下需要引入的变量赋值，输入对象的应该为一个 json 格式的字符串用于解析。

tenant_name：租户名table_name：表名database_name:库名index_name：索引名

tenant_name：租户名table_name：表名database_name:库名index_name：索引名  

示例：如下为一次调用的结果 record 的展示。

四、写在最后

联通软研院与 OceanBase 的合作不仅是技术上的交流，更是对未来发展趋势的一种探索。通过共建 obdiag 的新功能，双方旨在达成四个目标。

• 提升运维效率：通过自动化的故障诊断，减少人工介入的时间成本，提升整体运维效率。
• 增强系统稳定性：及时发现并解决问题，提高数据库系统的稳定性和可靠性。
• 促进技术创新：借助双方的技术积累，共同探索数据库领域的前沿技术，推动技术创新。
• 增强用户体验：为用户提供更可靠、更高效的数据库服务，提高用户满意度。

在此过程中，特别感谢 OceanBase 谢振江（花名：仓氐）提供的排查思路及流程，以及中国联通软件研究院靖永栋提供根因分析场景编码实现。

附录——

• OceanBase GitHub 仓库：https://github.com/oceanbase/oceanbase，感兴趣的 DBA 和开发者可以加入 obdiag SIG 进行共建开发。

• obdiag 下载地址：https://www.oceanbase.com/softwarecenter

• obdiag 官方文档：https://www.oceanbase.com/docs/obdiag-cn

• obdiag github地址：https://github.com/oceanbase/obdiag

• obdiag SIG 营地：https://oceanbase.yuque.com/org-wiki-obtech-vh7w9r/imzr6c