我也想看看是什么sql,这个应该是执行计划生成的不对吧。贴下执行计划。
1、当前使用的TiDB版本为:5.4
2、当前您在使用DDL时,还遇到哪些痛点?DDL 不同表的 DDL 不能并行处理,
3、还有哪些DDL功能是您迫切希望支持的?如果上述需求在新版本支持了,就没什么需求了,很好。
4、其他反馈和建议:已经很优秀了
可能的情况:
tidb 节点 oom
超过了事务大小,被 kill 了
忽略那么多细节,大概看看整体流程就行。我相信写代码的时候也不是全都设计的很好再在合适的地方加check,感觉是一开始一个大逻辑,后面加一点逻辑,就在相应位置加个 check,慢慢就加成这样了。
要么就先仔细看看每个模块,然后串起来。比如说 raft-rs 这个就是处理 raft 消息的,你想了解可以看看,如果了解了这个,后面遇到 raft.step 之类的就不用走进去了。看代码就快了。
基本上大的流程就是这样:
tidb=> grpc => scheduler => raft-batchsystem=>apply-batchsystem
其中向 raft-batchsystem 发消息…
你这个 add-peer 的动作倒是有,但是没加成功啊。
得看看日志了,比如说看看其中一个 operator 要在哪个store上加,然后看看store对应的tikv的日志。有没有什么报错
pd-ctl 看看其中一个 region 什么情况。贴上来。
kubectl describe pod xxx-tidb -n xxx
看看 Reason,应该是 oom 吧
我记得 operator 是不动 pod 的,operator 只操作 sts
目标就是为了防止因为强行下线导致的 leader 重新选举带来的性能抖动吧。提前手动让 leader 迁移到其他节点上就是为了避免这个的。
先把这个tikv的leader 驱逐走再停机操作即可。默认不超过30分钟的话,不会认为这个节点down,如果超过30分钟,再改个 max-store-down-time
pd-ctl -i
scheduler add evict-leader-scheduler
config set max-store-down-time 60m
多个tikv打标签分组,避免任意两台挂了会导致丢失多副本。
要求再严格的就cdc搞主从同步
【你最想实现的 TiDB 功能需求】 列存索引
【你最喜欢的 TiDB 新特性 + 理由】 当前的tiflash是能解决一部分问题,但是直接导致多了一幅本,有时候并不是每一列都有必要搞一个列存,能省点是点。
【你最想要周边心愿池里的哪个周边】 行李箱
【你考过哪些 TiDB 证书?】 PCTA\PCTP
【你身边有多少位朋友在用 TiDB?】 100+ (严格来说,这100+不算我的朋友,是我的上帝,我都没有100+朋友
)
最近遇到比较多的问题是:
业务方问:我的sql怎么突然那么慢了?
查看grafana,tikv的扫描多一些,就是grpc那个面板,看过去同一时间的对比,发现扫描多一些,那就慢了。扫描主要是:coprocessor请求。
这种情况就和业务方确认,是不是有上线,有sql变化?
如果没有的话,看看慢的sql的执行计划是不是选错了,比如说表的健康度变低导致的。
然后绑定执行计划,完成!
为什么要从rocksdb迁移到tikv呢?
数据量肯定会增多的。
tikv会对数据加一些后缀,支持mvcc
tikv还有lock相关记录,支持percolator事务。
tikv还有raft log
tikv还是3副本。
这都是额外的开销。
没开过,以前也不了解这个选项,tikv和tidb之间是grpc,是长连接,按你的描述,这个节省时间作用不大吧。
那不是报错 numactl 没安装吗,安装上呗。
numactl 是一个用于 Linux 系统的工具,它允许用户控制进程的 NUMA(非统一内存访问)策略。要安装 numactl,请根据您使用的 Linux 发行版执行相应的安装命令。
对于基于 Debian 的系统(如 Ubuntu),可以使用以下命令:
sudo apt-get update
sudo apt-get install numactl
对于基于 Red Hat 的系统(如 CentOS),可以使用以下命令:
sudo yum install numactl
或者如果是较新的系统版本,可能需要使用 dnf:
sudo…
趁早把leader迁移到其他pd上,然后重启或者直接重建这个pd得了。你这个集群这种状态多悬啊。