为了获得更好的功能、稳定性和性能，升级是必须的，但同时升级又是一个重大的危险变更操作，搞好了造福群众，搞砸了车毁人亡。 官方牵头提供升级专家服务，对社区用户来说是一大福利！非常支持这个活动

楼主这里每天百万级别的replace写入，其实并不高，很多用户每天写入都在亿行级别以上的，集中在某个时段的任务也有很多是几百万、几千万行的写入的。 这里的建议是需要搞清楚整个集群有哪些业务，这些业务是什么访问方式、对集群的资源使用情况如何，你弄清楚这些之后，就可以对高消耗资源的业务安排错峰运行。 鉴于楼主用的是 v7.1.0 版本，如果全部业务都不允许改变运行时间，就是无法避免会一起集中运行，那么还可以使用 资源管控功能，实现不同业务的资源使用隔离，避免相互挤兑和干扰影响。这里可以参考我之前整理的文章：专栏 - TiDB v7.1.0 跨业务系统多租户解决方案 | TiDB 社区 专栏…

很多业务场景都能正常用到replace方式插入更新数据。 楼主你的问题核心点不在于replace，而在于业务访问的规模、流量以及业务SQL情况。所以需要重点排查为什么TiKV CPU负载很高，通常来说是因为有大量的数据发生读取、写入，可以重点查看Dashboard面板，确认集群热力图情况，结合SQL语句分析、慢查询模块，找到对应SQL，再结合业务访问情况优化。

大佬你这视角切入得很是意料之外又在情理之中

目前的count扫描数据的并发是多少，如果太大就需要调小一些； 同时不要一次性执行过多的count，毕竟它也是暴力扫描数据的算子。

楼主问集群能否重启，首先你要确认是测试环境还是生产环境，如果重启会有什么风险。 考虑到你这边对TiDB还不是特别了解，可以先确认有什么业务在访问，集群异常会影响到谁，先通知到位。 然后再来调整这个内存使用高的问题，tikv使用内存过高是很少见的，大部分场景是因为同一台机器部署了多个节点导致资源竞争厉害，或者是tikv的参数 storage.block-cache.capacity 配置不合理，先往两个方向排查和确认，如果是就可以针对性解决。

通常隔一段时间就会在各地区举办活动的，后面北京应该也会有，留意社区公告即可

楼主的问题，本质上是一个加速count的调优问题。 Count 本身就是暴力扫表，可以使用 tidb_distsql_scan_concurrency 变量加大并发。 TiDB 每次执行查询时，都要访问 TiKV，所以加大并发度需要同时考虑 CPU 和 I/O 资源，避免调整过大占用过多集群资源，影响业务访问。 机器够的话，也可以扩容部署tiflash来处理，这个的速度提升是质的变化。

TiDB是一个分布式数据库，核心是三大构成组件：计算层节点tidb、存储层节点tikv、管理调度层节点tipd。 其中楼主提到的tidb-server 是属于计算层节点的组件实例，在主机上就对应一个tidb-server进程。 你贴的tidb server的结构图是计算节点的源码功能模块设计图，在物理部署上同属于一个tidb-server进程。 当然不同的功能可能会有系统参数或者变量提供给用户调整修改，以便让使用者获得最佳的用户体验。

期待各位老师的分享

向量查询为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…