会自动自动transfer leader 后，再补副本

这种情况直接缩容再扩容就行

3PC是什么

可以参考这个在pdctl中调整参数 https://docs.pingcap.com/zh/tidb/stable/pd-scheduling-best-practices/#leaderregion-分布不均衡

应该是bug，我找找

我寻思这个题目都出的不对啊

你升级到7.1的最新版本测试看看了

从图1 来看NO such files or directory 这个大概率是目录，或者权限问题。 另外导出报错不影响 listen task meet error would reopen。这个会重试，不影响整体备份 先查看leader分布，因为br backup会去备份leader。然后看total Range。集群数据量整体较小。造数数据量大点后再看看备份情况

tidb 冲冲冲

不需要强行，你-- force 缩容会自动transfer。觉得慢可以调整transfer速度

三节点 有坏掉一个节点去强制下线它时，首先需要先扩容一个节点 然后–force缩容下线节点。下线节点在region transfer完成后，会自动在pd-ctl中的信息中消失

之前好像就有碰到过类似的case，程序链接里面有单独设置不同的sql_MODE

留痕等个结论

数据量小直接insert 方便，大的话dumpling + lightning

TiDB 在迁移时不需要做分区表，分区键，底层key-value 自动划分region，这一点比起OB在迁移时要选好分区键要方便的多 同时TiDB扩缩容非常的灵活，可以选择扩容1个2个，N个 tidbserver ,tikv等。但是OB 生产环境扩容OBSERVER的话需要每个Zone都扩容一台。

你可以尝试一下，我这边测试6.5是没有问题的

[image] 直接这样建就可以，但是要满足插入的数据格式严格满足要求 [image] 否则就会发现在对应分区找不到数据

如果确定是热点问题，可以通过 tidb中hot_region_history确定热点region，,table。或者热力图也行。 后续对表进行auto_random的打散

block cache修改之后可以观察下tikv detail的block cache size有没有下降。另外.3上的内存使用有到瓶颈吗 虽然看到.3上的组件是挺多的。其次你这张图片上面提示的info显示的什么信息