key is locked 那里，有个key，看看那个key属于的region： pd-ctl region keys --format=hex 7AXXXXXXXX 能查出来属于哪个region 然后去information_schema里面找找属于哪张表。知道表能大概定位出来吗？别的办法我也不会了。

这个没试过，你如果tikv重启label不变应该就可以了。

你这个tp99真是不容乐观。业务这么能忍吗？

主要看store limit，如果你这个压力很大，那还是悠着点。

不影响，打上标以后应该会自动调度的。调度速度看着性能调吧，别影响性能。

大概率有的，几十k个region，不分组交叉的乱套了都。

能找到阿里的机架信息就按机架信息分组，这样更安全。找不到就自己逻辑上分组就行了。不分组混着来只能挂2个。

对tikv分组。告诉tikv(0-9)是一组，tikv(10-19)是一组，tikv(20-29)是一组，这样的话，组内只有1副本，组内随便挂几台都没问题，只要有2个组完整的运行，就不影响。 组可以从阿里看看有没有错误域之类的信息，把多台机器按错误域分组。比如说：同一个交换机，同一套电源，这就是一个错误域。

如果挂掉的2台对应的region只是普通的表，那就是这些region不能访问，如果这个region是meta信息，那tidb-server超过租期后获取不到meta信息，就整个集群不能访问了。 30多台机器还是建议分个组，按错误域调度。阿里应该有这种参数。

你有按机架分组码？如果没有，按host调度的话，任意挂两台都会导致一些region的双副本丢失，就没法提服务了。

一定等region变成tombstone才可以删除。否则就丢副本，然后期间再故障一台机器就不能正确提供服务了。

store limit all 200，完事儿。 如果影响性能比较多，就 store limit 15 改回默认值。

1t怎么也得8小时左右吧。不怕影响性能的话 store limit 搞大一些，弄个200

我是说，某公司老板喊了一句：成本、效率、体验，然后公司各种背语录，任何产都向这些靠近。在这里看到感觉有些熟悉。

成本、效率 差一个体验

以前我认为是会报错的，现在都自动补数了。牛！ 5.7是自动补数还是报错啊？

那wal关闭还能保证数据不丢这个事儿你再研究研究，怎么保证的不丢失。 你搞清楚后通知我下。

每次apply的时候执行flush这样性能很差啊，应该是在compact raft log的时候执行flush吧。

备份恢复不需要和原来节点数一样，region随时都在变的。