有些云平台是支持的，升级完可以试用一段时间再“提交”升级，“提交”前可以回滚降级。

查看索引使用情况，BR恢复提速

KV Request Duration 99 by store这个呢

看下这3个图呢 TiDB => Query Summary => Duration TIDB => KV Request => KV Request Duration TiKV-Details => gRPC => 99%gRPC message duration

SHOW TABLE t1 regions;找到表star_key前缀，比如t_119。 正常在tiflash目录肯定可以grep到t_119的目录。

看下tiflash配置文件，你可能配置呢多个数据目录 [image]

查看cluster_id方法如下： cat {{/path/to}}/pd.log | grep "init cluster id"

我理解他们都是逻辑的变更日志（相对redo物理的），都能用于同步和恢复场景，但是采用协议不同。

创建索引分两步：1.创建元数据；2.回填数据。 大表加索引慢一般是回填慢。索引相关有下图4个参数，通常用前2个参数控制回填速度。 [image]

Grafana配置数据不知道怎么持久化的，要是能直接查就好了

明白了，那应该就是TiKV 的rocksdb.wal-dir。 TiCDC节点还有个redo配置storage，应该对应的。

split主要针对读的，写自增可以alter成auto_random试下。 [image]

是的，监控项太多了，而且可能会被人挪动

可能是TiKV在生成变更日志时候产生的吧

事务之间按提交时间戳排序，同个事务内部只有一个提交时间的，应该再按记录的文本顺序吧

好办法，比导出bash修改再导入高效

我一般是换一个tag，丢弃历史数据 tiup playground --db 2 --pd 3 --kv 3 --host 0.0.0.0 --tag test202403

1万行1M的话，1行大概100Byte，一个字符占1Byte，一个Int占4Byte，可以放不少呢