这是发的什么配置？

相当于key变了，value也要跟着变。

有案例分享么？

tiflash节点是learner，这个好区分。

tikv的leader是指副本，每个节点上都有leader副本，这样才能分散计算压力。 [image]

只能三节点混部了吧。 每节点(台机器)上混合部署 1 TiDB(实例) + 1 TiKV (实例) + 1 PD(实例）。 https://docs.pingcap.com/zh/tidb/stable/three-nodes-hybrid-deployment/

没法查，不过一般来说不会有这么离奇的事情发生。 只能按你前面跟客户沟通的，换tidb节点了。

跟触发器应该没关系，因为是某个节点执行失败，不是所有节点执行失败。大概率还是这个节点的问题。 在243上执行 ADMIN CHECK TABLE 试试呢。 忽然又想到一种可能，会不会243的ip上新加了负载导致连到其他地方去了。 [image]

建议使用敏捷部署，支持GB级业务，单机模式~

这里集合~

看来是两种授权的处理机制不一样。

严谨的源码大佬~

不支持，估计只能迁移之后再处理了。

看来是遇到bug了，之前做过什么操作么？比如 断电重启，还原集群等~

需要手工在最外层加order by才能保证返回结果是固定的。

普通授权和上面的授权有什么区别？

额。。。这俩节点是一个集群嘛

之前没注意到有的节点执行成功，有的节点执行失败。感觉是tidb节点缓存的问题，重启一下243试试呢？

中间改过表结构么？重启一下243节点，再执行一下sql试试呢。