集群里有多少个 region？
升级吧
每个节点有8w个region，一共有15个节点
升级过程中会重启TiKV，现在手工试过重启一个TiKV节点后，leader不会自动迁移回来。所以不敢继续重启tikv了
因为集群用的是raw模式，tidb用的是txn模式，两者不兼容
看pd监控，大量调度都是超时
这个是个什么状态，是不是配置了什么，后面怎么迁回去的
那要检查下PD 的region 信息 和 tikv 的 region 是否匹配了，更麻烦了… 
集群正常时候，没有配置evict-leader-scheduler，重启一个tikv节点，1分钟左右leader会迁移回来。
上周我试过重启了一个tikv节点，发现leader迁移很慢，到今天都没迁移完，整个集群看起来是有一些节点leader多，一些leader少。
请问下，有哪些命令可以定位呢？另外我保存了tikv的内存火焰图，但是看不懂，应该怎样分析内存消耗在哪里？
leader的监控发下看看
pd的region 分数公式改过一个版本，就是因为原来v1的时候调度抖动。
20231121-PD_2023-11-21T09_46_41.982Z.json (3.4 MB)
监控如上
嗯，我们线上环境是裸kv的写入和删除qps都挺高的，各接近1w qps，不知道是不是这个引起。
v2版本算分是5.0后引入，要升级TiKV，现在希望看看是否能不升级TiKV能解决问题。
内存火焰图看的不是很清楚，可以把原始文件发上来看看。
另外，可以看下 TiKV-Detail 里的 Server → Memory trace 和 Memory。
不过我不确定这个版本是否有这两个面板。
1 个赞
mem.zip (24.2 KB)
内存火焰图解压之后可以查看
TiKV-Detail 里的 Server → Memory trace 和 Memory，该版本TiKV监控没有这两个指标。
裸KV
大佬，咨询一下。因为各种原因当初安装TiKV时候没有用tiup安装。如果想把4.0升级到高版本，是不是先用新版pd挨个替换旧版pd，然后再用新版tikv挨个替换旧版tikv 这种方式？升级期间tikv是可以正常工作的吧？
这里可能有两个问题：
一个是你们准备升级到哪个版本？直接从 4.x 升级到 6.x 或者 7.x 有风险，最好是不要跨超过一个大版本，即 4.x → 5.x → 6.x。另外，无论怎么升级，都建议做好测试和数据备份（br 的 rawkv 模式是实验特性，可以用，但建议同时做硬盘文件备份。文件备份要停机，否则数据可能不完整）。
第二，tiup 升级并不只是替换和重启，其中还包含 leader 驱逐等其他操作，来保证升级过程业务的无感。如果涉及到缩扩容，tiup 做的事情更多。没有 tiup 的话，手动运维会比较困难、而且容易出错。所以，强烈建议使用 tiup。
1 个赞
感谢回复，我们评估一下。