兄嘚们，今儿又遇到了这个情况，主键加个 `` 就可以了 ADMIN RECOVER INDEX xxxxxx `PRIMARY`;

【用开源版还是企业版，一般会基于什么考量？】 开源版本，我司好像就给oracle付过钱，自从去oracle后，一直就是mysql分库分表。可能也没有付费习惯。 【你所在的行业是？主要由哪类部门/团队/角色参与这方面的决策？】 电商，不知道谁决策

我记得有个 information_schema 下面的表里有，tikv_config 。你找找。

登陆tikv，然后看 /var/lib/tikv/last_tikv.toml

你看不到了那就是物理删除了，实际上还有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。