TiDB集群TiKV重启问题复盘分析

IT那活儿 2024-07-03

287

点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！

问题描述

2024-03-04 06:01开始系统数据库集群收到多条告警，经查看发现是3个tikv实例陆续报错重启触发告警，每个实例从down到完成重启，耗时约1分钟左右，重启完成后集群正常运行，3个tikv实例报错信息相同。

数据库集群指标收集：

排查分析

2.1 发现问题

发现问题之后，迅速对数据库集群进行了详细的排查。经排查，集群在重启前各项监控指标均未出现异常，重启后依然稳定运行，因此判断2024-03-04 06:00前后触发了版本bug。

2.2 定位问题

随即收集集群各项监控指标、tikv日志、版本信息等数据提单至开发排查，定位到该问题为产品bug。

原因如下：

tikv组件依赖tokio_timer库存在bug，进程运行超过2^36ms，约795天，会出现“index out of bounds”错误，后续版本已修复该问题。

2.3 问题确认

经对比分析：

与监控数据对比，重启的3台tikv实例运行时间均为2年;
tikv当前版本为v5.1.2，不在fix版本中（fix version: 5.0.7, 5.1.5, 5.2.4, 5.3.1, 5.4.1, 6.0.0及以后）
tikv报错信息、堆栈日志与该bug完全一致，故障现象也一致。

因此可以确认本次故障是由于触发tikv版本bug导致。

2.4 后续措施

本次事故后需确认使用TiDB集群版本，排查可能会出现故障的集群。

解决方案

方案1：定期重启

对出现该故障场景分析可知，定期在流量低峰期重启存在该bug版本的tikv，可对该bug做到可控处理，规避在流量高峰期对生产造成不可预估的影响。

方案2：版本升级

若要完全解决该bug，需要将可能会触发该bug的TiDB集群，升级至v6.0.0版本以后。在完成升级之前，依然需要通过重启tikv规避该问题。

结论：

针对于2024-03-04 06:00左右系统tikv重启故障，主要是由于tikv运行时长超过795天，触发版本bug导致3个tikv实例陆续重启，tikv自动重启集群恢复正常。

出现该故障后，排查其他可能会出现同类故障的TiDB集群，暂时可通过重启tikv节点规避。若要彻底解决该故障，需要排期将集群升级至故障修复的版本。

END

本文作者：王润枫(上海新炬中北团队）

文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。