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～ 这样也行，，

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

spark 的问题就不好解了，看看能不能绕过去

是 native SQL 未按照预期执行，还是 spark SQL 未按照预期执行呢？

目前没有直接的解决方案，只能曲线～ 可以采用外表挂载的形式，来实现历史数据的搬迁 增量数据必须采用 ticdc 了 历史数据还有别的搬迁办法，多得是，但是要考虑应用的场景和难度了 DDL 就没什么好办法了，一个是 TP 库，一个是 AP 库，结构都不一样，没法直接用的 AP 库，如果 tiflash 能满足使用要求，可以试试

这个事情要分开看， 旧的业务搬迁 新的业务构建，来代替旧的 新旧交替 要根据实际的情况来制定策略了，并不是看代码和写代码那么简单了。 存储过程一般都是几万行的哪种，可以看哭～ 建议用 AI 进行分析了…

only ticdc → kafka → es

没，这是规划就要考虑清楚的

木桶最短的一块板，限制装水的能力

难怪了，配置要一样才可以。不然就是木桶短板了

2 和 3 节点会比较热，读写都到了 GB级了, 磁盘硬件最高能支持到这个规模的读写的 IO 么？ 不行的话，会有延迟了。

对，看看各个 tikv 的 IO 是否正常。在那个峰值时间周期内

yes， pls check it with grafana in the different module

峰值到 1.6 min， 继续检查 磁盘 IO 的情况，同一时间

看起来是网络问题，查下 gRPC 是否被打满了