感觉可能跟这个 BUG 有关系，触发逻辑也是替换所有的 PD 后触发的，可能 truncate table 会走到 PlacementManager 逻辑，所以报错了。不过这个在5.4.3已经修复了，也可以升级集群试下。
还是你 truncate 的那个表用了Placement Rules in SQL? 看5.4确实已经支持这个特性了，show create table 看下表结构？
既然已经重启多次集群了，感觉可以升级到5.4.3版本试下，看下还会复现么，看了下 release note 没有引入什么兼容性变更
现在是所有的表执行truncate都报错 
这个PlacementManager可以强刷一次吗
先升级到 v5.4.3 试试吧
升级到5.4.3了，还是不行，我们把旧节点下了后，truncate一直报错访问旧节点： failed to get old label rules from PD: Get “http://pd-a:2379/pd/api/v1/config/region-label/rules/ids\”: dial tcp pd-a:2379: connect: connection refused”]
然后我们想了个方案，在旧节点的机器上搭了一个nginx 转发，只要是访问旧节点2379端口的，都给它转到新的pd节点，目前执行truncate, rename正常。
目前集群信息：
pd: 0.11.16.2, 0.11.16.4, 0.11.16.5
tidb: 0.11.16.2,0.11.16.4, 0.21.14.131(后续下线),0.21.14.134(后续下线)
nginx info 日志打印如下：
0.21.14.134 “GET /pd/api/v1/config/region-label/rules/ids HTTP/1.1” 200 3 “-” “Go-http-client/1.1” “-”
0.21.14.134"GET /pd/api/v1/config/placement-rule/TiDB_DDL_668332 HTTP/1.1" 200 100 “-” “Go-http-client/1.1” “-”
问题：
1、 我登录0.11.16.2的tidb server执行truncate， nginx的info日志打印的是0.21.14.134过来的呢？
2、为什么get 访问这两个接口，还是从已下线的pd获取呢？
Hello，
问题一：这个应该跟 DDL owner 有关系，DDL owner 应该是在 134 那个 tidb 上，所以其他 tidb 执行的 DDL 语句，最后会让这个 DDL owner 去执行。
问题二：v5.4.3 的 PD 地址是通过 PD members 获取的 https://github.com/pingcap/tidb/blob/v5.4.3/store/driver/tikv_driver.go#L232-L247
可以用 pd-ctl member 确认一下旧 PD 是否已经下线。
找到问题了：
1、当前0.21.14.134是ddl owner，134机器的tidb服务有两个4000端口的进程，一个是新的，一个是旧的(旧的节点在对外提供服务且使用tiup扩容后该tidb的–path=pd旧节点信息)
2、使用tiup重启集群，134机器的旧节点未重启，pd信息仍是旧的，并对外提供服务。新的tidb4000节点服务重启，tiup restart日志打印集群重启成功(实际旧的没有重启)。
3、kill掉旧的tidb服务，重启当前节点的tidb server，truncate table 执行正常！！！ (注:为什么同一台机器会起两个tidb4000服务，原因不知)
在此感谢tidb官方同学的大力支持 。