主要是你的条件里面是子查询,相当于要和别的表进行关联吧,类似你select * from a join b join c和select * from a join c join b了,你实际执行下analyze explain看下一样不,哪个更快?
其实pd和tidb-server不怎么占磁盘的,1T浪费了,这三个机器应该各匀一点给其他四台tikv机器的。。。。
会的,像 LOAD DATA 或 INSERT INTO SELECT 直接导入数据一般都建议手工anaylze下表的
根据 TiDB 的设计,健康度公式为:
Healthy = (1 - Modify_count / Row_count) * 100
当 Modify_count(自上次统计信息收集以来的数据变更次数)为 0 时,健康度自然为 100。但这仅表示统计信息未因数据变更而过期,不保证统计信息中的行数与真实行数完全一致。例如:
数据导入场景:如果表通过 LOAD DATA 或 INSERT INTO SELECT 直接导入数据,但未触发 Modify_count 的更新,即使真实行数大幅增加,健康度仍可能显示为 100
是分区表吗?不是的话,ANALYZE TABLE tree_node WITH SAMPLERATE 1.0;这样收集以下再看看呢?
如果是测试环境简单测试的话,建议直接用tiup playground v6.5.8 --host 0.0.0.0 --tag smk-test --without-monitor --tiflash 0命令一键启动吧,一台机器没啥好集群部署的。
别看tidb-server的日志,tidb集群的启动顺序是pd→tikv→tidb-server,现在你的tikv都起不来,先排查tikv不能启动的原因
查看集群状态,不需要ssh登录到其他主机上的,是调用的各个节点的api获取的状态,但是关停需要执行系统命令,所以要ssh登录
tidb上先试一下
SELECT * FROM sys_org LIMIT 1;
能不能查询
每个tikv会把自己的备份放到各自节点上,一般建议指向一个共享存储nfs/s3之类的,如果是本地目录就要汇总一下。
2个副本和1个副本没区别的,都是挂一个直接废。。。。
至于在线改副本数量,主要影响的是tikv的io,pdctl改下pd store limit ,改小一点,应该会慢一点删除副本,影响没那么大
检查 Region 分布 :通过 SHOW TABLE REGIONS 查看目标表的 Region 分布情况,确认是否存在 Region 集中在单个 TiKV 节点的现象
现在在恶补大模型相关的知识,确实以前引以为傲的经验现在越来越变得微不足道了。。。
你现在可以在tidb和pd机器上测试访问通tikv机房的ipv6地址吗?ping和telnet,如果可以的话,单独配置tikv的host为ipv6也没问题
tidb-server,pd,tikv,全部都可以配置成ipv6
应该是你对这里的schema理解有点问题,这里的shema相同是指的表的 逻辑表结构、索引等元数据完全一致,不是指他们所属于的schema一致。
TiDB集群是6.1.4,BR工具是6.2.0之后的版本,也可以实现pitr的功能,但是不保证不出现其他的问题。。。