遇到的几个不正常的PD问题

h5n1 · 2022 年2 月 25 日 01:41

【版本】v5.2.3
【背景】
有条SQL导致tidbserver 耗尽空闲内存最终oom，调整tikv blockcache并reload(开始以为是3节点混布的集群就直接调整了cache)，后因怀疑bug或优化问题升级到5.2.3 过程中遇到了PD相关问题。

【步骤】
1、 edit-config 修改tikv内存配置后reload，reload过程中的第一个tikv失败，然后tikv down，多次尝试reload同样问题

2、后发现有个67.85 PD down状态，tikv日志有一些mismatch报错(67.85 down有可能是之前有另一套测试集群操作时影响)
PD response cluster_id mismatch, want 6961340219970978631, got 7031811607061592721")"]

3、通过缩容方式将down 的PD移除后，tikv正常启动，后又将缩容的PD扩容回来

4、计划在线升级集群到5.2.3, 升级过程中PD节点67.84最先重启，显示成功够又报failed，尝试2次均失败

4、使用offline方式完成升级
5、升级完成后启动集群，tikv启动失败

6、检查tikv日志报错cluster id mismatch

7、缩容2个PD，删除最后一个PD的data文件，使用pd-recover方式恢复PD集群后正常

【问题】
1、 PD集群是多数可用即可，为什么在最初PD 67.85 down后导致tikv启动有问题？
2、 PD集群虽然有扩缩容操作，但剩余2个是一直保持正常的，为什么offline升级后集群的cluster ID就变化了，中间的哪步造成的影响，原始的2个PD节点是一直可用的？

tidb操作日志.txt (2.3 MB)

robert · 2022 年2 月 25 日 10:23

有可能unsafe recover cluster id 搞混了

h5n1 · 2022 年2 月 25 日 10:51

这集群没做过unsafe recover

spc_monkey · 2022 年2 月 28 日 02:11

只能通过pd 日志来看了

robert · 2022 年3 月 1 日 04:09

有没有删除过pd的data 目录，如果没有，可以发一下那段时间pd的日志么。

h5n1 · 2022 年3 月 1 日 04:12

当晚是没有删过的就是把down的pd扩缩容，以前的话可能没印象了，这个集群一直是正常跑着的

dbaspace · 2022 年3 月 1 日 04:40

通过tiup管理集群，集群节点是down状态，reload会变UP状态的，是这个引起的吗，之前缩容有做集群更新没

h5n1 · 2022 年3 月 1 日 05:08

不是reload的变成up的是，3个pd 缩容一个问题pd后又扩容的

robert · 2022 年3 月 1 日 06:10

[quote=“dbaspace, post:7, topic:573893”]
reload 会变 UP 状态的，是这个引起的
[/quote]我看这个集群是做过recover以及删除data 目录的操作，在剩下一个pd节点的时候。

h5n1 · 2022 年3 月 1 日 06:19

这个是后面offline方式升级完成后出现cluster ID mismatch后的操作
1、 tikv 因为一个Pd节点down ,于是缩容该PD，后tikv正常online。然后又扩容该PD
2、在线升级到5.2.3 重启时pd启动失败。
3、offline方式升级，tikv启动失败，检查日志报cluster id misacth
4、缩容2个pd,删除pd data后执行pd recover，后增加2个pd节点后集群正常。
在第3步前pd是正常的, 1步前始终有2个pd是正常的

robert · 2022 年3 月 1 日 06:21

PD的log可以导出来么

h5n1 · 2022 年3 月 1 日 06:41

pd-2022-02-24T22-15-22.619.log.gz (22.7 MB) pd_stderr.log (293.0 KB)
当晚是8点后开始登陆处理SQL oom问题

robert · 2022 年3 月 1 日 07:29

仔细看了一下日志和代码, cluster-id 生成规则如下：
https://github.com/tikv/pd/blob/22cef409abdb8522e471c79c239826430f2b78c7/server/util.go#L86-L123
6961340219970978631： 1620813324s -->2021-05-12 17:55:24
7031811607061592721： 1637221222s -->2021-11-18 15:40:22

如果是pd的data目录在升级过程中被删除或者损坏的话，其对应的时间戳应该是2022/02/24。有没有可能是集群弄混了，或者其他的集群误操作了。

h5n1 · 2022 年3 月 1 日 07:51

最早down了的那个pd，有可能是弄混了，其余2个正常的应该没有的。你可以看下操作日志里搜索下scale-in ，先scale-in pd-85,然后start tikv正常后，scale-out pd-85,之后check culster。然后upgrade 由于ssh报了一次错，后改成–ssh system 后upgrade, pd-84重启报失败后offline升级的

h5n1 · 2022 年3 月 2 日 13:50

看了下最初重启的这个tikv实例也是因为cluster id mismatch问题起不来，看来是之前cluster-id就已经有问题了，但是没影响集群运行

h5n1 · 2022 年10 月 31 日 19:18

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。