BR 是物理备份，恢复的时候有要求的 dumpling 是逻辑备份，数据量大的时候不太友好，导出慢 但是通过 lightning 写入还是可以的，逻辑的更方便控制 加油～

独立的盘，肯定是 独立的 IO，肯定性能会好一些了 如果在生产上，就不要随便切换了，最好先去 UAT 或者 POC 的环境测一测先

整的老复杂了，光看就觉得很痛苦了

不能停机维护么？ 停掉维护好了在上线，不就ok了

描述的情况，应该不适于用 Region remove 如果不是 leader Region，通过 tikv-cli ，就可以remove 了 https://docs.pingcap.com/zh/tidb/stable/tikv-control/#设置一个-region-副本为-tombstone-状态 建议采用复制表数据，重建的方案，待新建的数据表确定没问题后，在处理原来有问题的数据表

好嘛，我提的问题，， 只有Git 是最好的办法了…

这个 Region 对应的表，是否还存活？ 如果这个表不需要了，可以尝试 Drop table 或者 remove Region 试试 好像没有办法清理 lock 信息，这个是 GC scan 需要去自动处理的

那有可能是bug 了，看看是不是已经修复的，7.1.X ，可以升级试试 [image]

[image] 是不是什么冲突导致的，这个锁信息丢了？ 可以看看这个场景是什么问题

用什么方式修改的这些配置参数？

tiup 就是最简单的，没有其他的好办法

检查下 磁盘的 IO 情况，可以通过 grafana 查阅指标 或者 登录到 tidb 节点上，直接查

日志不都写的好清楚了，缺少认证组件： mysql_native_password

你选版本好歹选个 LTS 吧，选个 DMR ，有bug 都没 fix version 继续发布，你怎么更新呢？ 那只能大版本升级了，可以考虑下… 如果是在生产，那就比较糟糕了

那就围观先

这个没太多关系拉，可以继续学习了

【简化技术栈是一个必然的趋势吗？】 必须，不然Team 的压力太大了，工作量也是会成倍增加的 【在使用 TiDB 过程中，有哪些优质的极简开发体验令你印象深刻？】 Tiup 的体验已经很牛了，没得说

7.1.x 7.5.x 8.1.x 8.5.x

Store-1 这个节点和其他节点的时长差很多哦，可以看下是否有读偏斜导致的 cop 缓慢？