你看不到了那就是物理删除了，实际上还有132个region的副本指向了这个tikv。有大多数副本存在的前提下，pd的调度也不依赖这个tikv活着，可以用另外两个副本构建出一个新副本，然后补上。最终都补完后，这个tikv上的peer就变成0了，状态就tombstone了。

等这个状态变成 tombstone后就可以删掉了。 现在还有132个region peer 需要迁移

tidb 不是起不来吗。起不来的话，最后得有一条 fatal 的错误吧。把那一条贴上来看看。

tidb节点起不来报什么错？最后的fatal日志发一下。

es、doris 有些业务是从tidb结转到es，我就想知道这个 es 和 tidb 对比有哪些适用场景

期望看到执行计划介绍相关的文章，比如说 in 后面带多少个字段会选择全表扫描之类的

tidb 的binlog 和 mysql 的binlog也不一样格式。不过这个在老版本上有过，新版本有没有继续搞不记得了。 标准用法就是楼上说的，cdc->kafka 再自行消费到其他产品中

没问题，你随便迁移，只要节点不是物理销毁、断网之类的，pd会保证数据的3副本可用。

缩容失败几乎没遇到过，就是迁移数据，动作也基本上就是平时的region平衡，只不过下线就是把 region 平衡改为往别的节点挪，并且速度可能会快点。除非说磁盘在迁移过程中挂了，机器网络在缩容中断了，那缩1个还是缩多个，都一样。正常运行也会遇到这些情况。 如果说缩着缩着不想缩了，直接 curl -X POST http://pd:2379/pd/api/v1/store/${store_id}/state?state=Up 改成 up 也可以。 或者如同上面几位大神说的： store weight 0 0 改权重为0也一样，最终目标就是把上面的数据挪走。 对了，还有就是磁盘不足，缩…

可同时store delete 5个，不影响，store delete 5个并不是说5个下线了，是要把这5个上面的数据全迁移走。 我经常这么干，线上如果有缩容好几个的，我就把后面几个同时执行 store delete ,避免 最后节点的数据挪到倒数第二个，然后再从 倒数第二个往前挪。 store delete ，把store状态标记为 offline，只是一个状态，只影响 pd 的调度。 在真正 tombstone之前，这个store还能正常提供服务。所以放心大胆的搞就可以。没什么影响。 别加 force就可以，加了force就相当于标记了物理删除，那如果标记了2个，就可能导致2副本不可…

store delete 的时候，就不会往上面调度了吧。offline的时候基本上就是往外挪。

你现在是 pending offline，可以等待 store 状态变成 tombstone ，就可以随便移除换盘了。

需要在泰国中转么？

operator成熟度很高，可以全自动完成大部分工作 不过有一个点不知道有没有实现： k8s 的一个 node 预计要坏掉了，得迁移上面的所有 tikv，这个过程全手动，有点累人。 为什么呢? 因为 tikv 是本地盘，得通过 store delete 把 store 下线后才可以切换节点。 这里就有人要问了，为啥不直接物理销毁。 因为如果物理销毁的话，再点背遇到了真的断电、断网的情况，那集群就不可用了。所以但凡是能正常下线，就正常下线。 如果谁知道 operator 已经支持了我说的这个动作，可以教教我怎么搞。

polardb 是个怪物 [image] 不过说实话，确实做的还不错，成本很低，一两个节点就能带很多数据。并且延迟比较低。 好像单表很大的话表现不如 tidb。

08年奥运会的口号：更高更快更强！用在 TiDB 也是很合适的！

[image] 你的 operator 版本好像有点高，不一定能支持 4.0.7 吧 把 operator 版本降下来再恢复吧。

可以恢复，把crd装上，建一个同名的实例就行了。建议先找个别的资源测试下。

问题已解决： 仔细看了看pd的监控，发现 operator 生成的速度就是15，突然想到是不是原来 store 的 store limit 限制的。 我原来的 store 已经强制下线，store limit 看不到。 [image] 通过强行执行 store limit 1 1000 remove-peer 后，速度一下就上来了。 [image]