force 强制重启 或者修改timeout
reload xxx --force 这样？
–transfer-timeout xxx
region多 就设置时间长一些 最好不用force
重搭之后 目前还没发现 truncate 后的表有问题,但是旧的有数据的表问题查询 还是有问题
现在tidb有在报这个错误 [2022/11/18 08:54:58.176 +08:00] [ERROR] [distsql.go:1201] [“table reader fetch next chunk failed”] [error=“[tikv:9001]PD server timeout”]
先确定之前的问题是否已经解决？
按照道理 现在新增表 应该不会有问题。
你之前的表。由于alloc id问题。可能还是会有问题
昨晚到现在truncate 后新入数据还没问题，目前还在跟踪日志
OK。建议有问题的表。就重建吧 重新导入数据。
pd 重建，alloc id 最好使用一个比较大的值，一定不能使用比之前小的值。
后续如果还是有问题，使用clinc 发出来再看下。
导入不了呢 ，
数据就一份 旧的查不出来
应该是小范围的表有问题吧。这个我这边也没什么好的办法，
之前说的删除 索引。重建索引试过了吗
USE information_schema;
DESC tikv_region_status;
查下这个表。看下是否有重复的region id
试试设置tidb_snapshot 或tidb_replica_read = ‘follower’ 能不能读出来
其他办法导出数据不行 我就试试这个
数据有点多，环境也有在人用 重新搞一套需要时间比就多 ，目前只能先修复部分
分组去重。看看是否有region id 相同超过4个的。
具体的表 去掉，有可能是其他表的region
我跟 STORE_ID 去重 是没有超过3个
