期待各位老师的分享

向量查询为TiDB开拓了一片广阔的新领域，可以极大丰富产品的功能特性，覆盖更多的用户场景需求。 显然，这使得那些有图片、视频等更复杂数据存储和搜索的场景，有了更多的数据库选型方向

不一定是root，其实就是你登录中控机使用tiup 的那个普通用户就行。

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。

这是当时远端镜像访问出现异常，官方已及时修复。 重试就可以解决问题。

如果期间你没有用tiup执行过 扩容、缩容、调整配置文件等内容，那就没有变化。如果有用tiup调整过，内容就会有变化。建议是定期备份。tiup 这里记录是运维管理相关的元数据，DBA有过操作，这里的元数据才会有变化。和集群数据的元数据不是一个概念，集群的元数据是存在在pd集群，和这里讨论的内容没有一点关系。 ~/.tiup 目录是在你集群的中控机机器、安装集群的用户上，到那台机器上去查就行。

报错的原因是这里，出现了FATAL的异常日志。 搜索关键字错误，看到有类似的帖子，可以看看是否有帮助： 目前集群状态各个节点正常吗？pd有几个节点，除了这个外是否都正常？

你查看了pd的日志了没，去确认一下

这个是高危操作，会直接强制抹除目标节点的部署目录和数据，谨慎执行。 先确认下在操作的过程中出现了什么问题，根据具体问题来处理

tikv的CPU和云盘读写BPS飙升，说明有大量的数据正在被访问，要解决问题就先弄清楚是谁来访问这些数据，所以排查 思路可以有下面几个方向： 先去Dashboard面板看一下topSQL、慢查询、SQL语句分析、热力图等，从整体确认下集群的运行状况。 在tikv节点使用资源升高期间，确认业务访问访问情况，查看QPS和延迟，确认业务访问量、访问链接数、负载等是否有变化 tikv长时间维持高访问，如果是SQL访问的，说明一定会有慢SQL出现，可以通过Dashboard或者慢查询日志尝试寻找对于的慢SQL，然后分析之。 如果业务负载没有变化、也没有慢SQL，就开始重点排查下tikv的Graf…

这个SQL是不是执行很多次，有可能是你截图的SQL，与在Dashboard上点开的不是同一次执行。 从你发的这个Dashboard截图来看，生成执行计划的时间太久了，SQL执行时间是302ms，而生成执行计划耗时209ms，占了接近70%的耗时，这里明显不正常。 可以重点关注一下tidb-server 的资源使用情况、运行日志等监控内容

如果要备份tiup元数据，避免中控机宕机，实现可以有两个方式： 备份使用命令 tiup cluster meta backup 写脚本，直接定期备份一下~/.tiup目录就行，里面包含了纳管集群的拓扑信息和配置文件。

对的，应该要纳管的，建议生产环境都定期备份一下~/.tiup目录

explain analyze的过程可以确认每个环节的执行消耗时间 如果是慢查询SQL，你可以登录集群的Dashboard业务查看SQL语句分析或者慢查询板块，里面的可视化做得比较好，一眼就可以看出是在计算层计算慢还是在存储层取数慢，非常方便易用。

tiup作为单点的管理组件，应该要备份一下，不过这个点很多人很容易忽略。 在另外一台机器重新下载tiup，逆向重新编辑集群拓扑和写入配置参数，应该可以恢复，大佬可以在测试环境试试。

目前提供的信息有点少，不好分析原因，请给出这个表的表结构还有执行计划 建议也到Dashboard页面上确认下这个SQL慢在哪个环节，可以很直观看到分析过程

从这个时候开始的，是真正的骨灰级用户了

简单理解为曲线的每个点都是一小段时间内的均值，所以会有小数出现

一种做法是把集群的慢查询阈值调大到10s，然后获取到prometheus里的慢查询，配置alertmanager就可以发送对应的告警，这个是相对比较简单的方式，可以最大利用现有的组件功能。 另一个方式是保留原有的慢查询阈值，通过收集集群的全部慢查询日志（实时采集全部日志文件，或者读取系统已经帮忙汇总的系统表都可以），过滤找出超过10s的SQL，然后再导入告警平台将消息发送出去。这个方案要求的技术栈和能力会高一些。