【TDengine 使用环境】
生产环境
【TDengine 版本】3.4.1.6
【操作系统以及版本】centos8
【部署方式】非容器部署
【集群节点数】3
【集群副本数】1
【描述业务影响】系统崩溃重启，导致无法查询写入
【问题复现路径/shan】系统正常运行中突然无法使用
【遇到的问题：问题现象及影响】
【资源配置】16c 32g
【报错完整截图】使用gdb 分析core文件的结果
1、您是执行什么业务时出现的 crash ？是查询 or 写入？
2、您的环境中有创建 流计算吗？
1.我们是线上数据库，所以查询和写入都有，而且是大量写入和查询，但cpu和内存都是正常范围内，当时没有做额外操作（命令行），就是线上正常跑的，分析core文件说是select ts,meas_code,create_time,val,number_value,data_type,operate_id,station_id,node_id,tbname from settle_d where (station_id = ? and node_id = ? and meas_code = ? and ts >= ? and ts".. 这条sql引起，station_id 和node_id 是tag并且建立了索引，meas_code 和ts是联合主键，这个sql以前跑也是正常的，ai给我的解释是两个索引导致了混乱,下面是ai分析的结果可供参考
2.我们没有流计算，只是用无存储和查询捂脸数据
那有可能是撞到某个bug了，请升级到最新的版本后，再看看吧。
如果仍然出现，请联系我们远程来分析。
我的服务器在 出现崩溃产生了core文件的时候 服务器在自动重启后 选举leader 花费了大约2个小时，他是一个一个vgroup 去完成的，如何在崩溃后快速恢复提供服务
选主不可能要这么长时间，一般选主就几秒的时间。一共有多少个 vgroups？
最好是升级到最新版本后看看是否还出现问题。
正常选举是没有的，但是在崩溃产生core文件的情况下，选举需要很久,需要一个一个的恢复， 我一共96个vgroup,
你先升级吧，再看是否还有崩溃的问题。