stop 不就可以了？ 参考这儿 https://docs.pingcap.com/zh/tidb/stable/dm-manage-source/

还是得看看更详细的错误信息才能判断

TopSQL 的数据保存期限大家一般会设置多久？ 默认的就可以了 除了现有的 cpu 指标，大家觉得哪些指标比较有必要体现在 Top SQL 里，在定位问题/监控时，大家需要看哪些常用指标？ 内存指标也是需要的，可以看到节点的内存使用情况 有没有一些在其他数据库看到的比较有价值/有帮助的指标，在 TiDB 里没有的（也可以分享下，我们多多进行优化改进！） 目前的指标够多了，大部分都在grafana中，dashborad 中差不多够用了

[image] [image] 健康度准么？差这么多…

看下 PD 关于 Region 部分的监控指标，特别是 empty region 和 unavailable Region

光部署和运维都可以让你很痛苦了

MVCC 是版本记录咯 这么老的版本，该升级了

这个问题不能这么问，要反过来看 研发为了省事，会学习 tidb 相关的技术么？还是你来全盘来把控？ 如果你来全盘把控，还需要哪些支持？

自己做个Filter 不就行了

RocksDB 大概率会跟着TiDB 的主版本走了，因为要考虑兼容 至于 Titan 和 RocksDB 关系不大了，blob 或者 text 数据外置存放了，模式不一样

https://docs.pingcap.com/zh/tidb/stable/tikv-control/#手动-compact-整个-tikv-集群的数据 https://docs.pingcap.com/zh/tidb/stable/garbage-collection-configuration/ 参考下，这个不能替代正常的GC，可以手动合并 tikv 的数据版本

手动跑 GC 命令试试

最常用的测试工具有哪些？（比如 Sysbench） 直接使用AI 生成数据 或者生产数据，按照实际场景测试 在测试中，更看重哪些性能指标？ 简单的增删改查，在海量数据下，结构上的不足或者索引利用率不够，就会暴露 有什么调优经验可以分享？ 唯一的经验：拿海量数据压测… 针对每个发生的问题，逐个场景排查和优化

mulitpe Raft … Log snapshot 是一个 Raft Data apply 是另外一个Raft Look this picture… [image] 阻塞式的处理，是不是让整个 tikv 塞住，然后挂掉？反向思考，就可以了… RocksDB 也有 WriteStall 的限流保护… 生产过多，消费过少，不平衡就都不行

打算怎么弄？

慢查询参考官方文档： https://docs.pingcap.com/zh/tidb/stable/system-variables/#tidb_slow_query_file https://docs.pingcap.com/zh/tidb/stable/identify-slow-queries/ https://docs.pingcap.com/zh/tidb/stable/information-schema-slow-query/#slow_query

慢查询 有专门的记录，开启了就可以查到的，而且是按照时间记录的。 RU 的问题只能慢慢测试了，先解决慢查询的问题吧，这样可以缓解 RU 受波动的情况

wow～ 这样也行，，

又想分布式数据库，又想支持分库分表，不是不可以，这个成本…