emqx 5.1.6 集群脑裂

环境

  • EMQX 版本: 5.1.6
  • 操作系统版本: Linux inst-8qxsq-emqx-replication 5.15.0-103.114.4.el8uek.aarch64 #2 SMP Mon Jun 26 10:27:39 PDT 2023 aarch64 aarch64 aarch64 GNU/Linux

重现此问题的步骤

1.新建集群 2 core + 2 replicant
2. 挂测100w连接

./bin/emqtt_bench sub -h yace.xxx.com -p 11883 -c 50000 -n 500000  -i 50 -k 120 -S -t %i -q 1 --ifaddr 10.71.4.75 -l --force-major-gc-interval
./bin/emqtt_bench pub -h yace.xxx.com -p 11883 -c 50000 -n 500000  -i 50 -k 120 -I 100000 -S -t %i -q 1 --ifaddr 10.71.5.19 -l --force-major-gc-interval

预期行为

一直保持在同一个集群

实际行为

集群脑裂

日志

replicant 变 core的节点
emqx-201.tar.gz (1.2 MB)

另外一个replicant
emqx-254.tar.gz (744.4 KB)

两个core日志
emqx-core1.tar.gz (664.3 KB)
emqx-core2.tar.gz (824.9 KB)

详细细节

  1. core 节点: 10.71.2.123 10.71.3.143
  2. replicant节点: 10.71.3.201 10.71.3.254

集群脑裂成2个集群


两个集群分别都有对方的主题:
7b834c71ae011413bae65405efb472a

配置中是role 是replicant
但是连接上10.71.3.201 webui 时,role 是 core。

这环境坏得有点彻底,
基本上所有的节点都无法访问etcd,pulsar,http,只要是对外的网络,基本全都挂了。
想问一下,你期望在这个场景下还能干什么
看到的topic应该是以前就在那里的。但是网络断开后,后期就不会再同步了。

@zhongwencool 那是前期的日志,目前访问etcd、pulsar、http都是正常的。 我主要在意的问题是为何同一个集群会分裂成两个。

退一万步说,就算访问etcd、pulsar、http都异常,也不应该分裂成两个集群。

正常情况下,只要emqx 节点 内部的还能通信,就不会成为两个集群。
应该是你选择了 etcd 做为集群选主,当,etcd 的核心服务都挂掉时,每个节点就不知道现在是什么情况么。他得能访问etcd。

@zhongwencool 昨天下午18点左右我看集群还正常,脑裂应该是发生在昨晚,昨天到现在etcd是一直正常,没有访问etcd报错的日志

哦抱歉,我看漏了,昨晚确实有访问etcd异常的错误。

@zhongwencool 只有这一个节点访问etcd异常,估计是这个节点网络的问题,不过我还有个其他的疑问:

  1. 恢复访问etcd后,没有合并成一个集群;且etcd key没有此节点信息
1001@etcd:/opt/bitnami/etcd$ etcdctl get  --prefix ""
emqx-cluster/ekkacl/nodes/emqx-613b@10.71.2.123
emqx-613b@10.71.2.123
emqx-cluster/ekkacl/nodes/emqx-b5bb@10.71.3.143
emqx-b5bb@10.71.3.143

感觉因为访问不到etcd导致脑裂不应该出现

  • 你说的只有一个节点异常,和我看到的日志中的集群所有节点有异常日志不一样。

  • 感谢反馈,我们会测试修一下恢复etcd后没有重连的crash。

2023-09-07T02:08:46.079540+00:00 [error] msg: Mria callback crashed, mfa: mria_lib:exec_callback/2, line: 226, callback: start, error: {badmatch,{error,{ekka,{{shutdown,{failed_to_start_child,ekka_cluster_sup,{shutdown,{failed_to_start_child,ekka_cluster_etcd,{{badmatch,{error,[{{"dev-etcd.meross.dev.vpc",2379},{shutdown,ehostunreach}}]}},[{ekka_cluster_etcd,init,1,[{file,"ekka_cluster_etcd.erl"},{line,357}]},{gen_server,init_it,2,[{file,"gen_server.erl"},{line,851}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,814}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,240}]}]}}}}},{ekka_app,start,[normal,[]]}}}}}, stacktrace: [{ekka,start,0,[{file,"ekka.erl"},{line,97}]},{mria_lib,exec_callback,2,[{file,"mria_lib.erl"},{line,220}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,240}]}]
2023-09-07T02:09:07.465426+00:00 [error] Failed to connect ETCD: {"dev-etcd.meross.dev.vpc",2379} by {shutdown,ehostunreach} mfa: eetcd_conn:fold_connect/5 line: 205
2023-09-07T02:09:07.465831+00:00 [error] Supervisor: {local,ekka_cluster_sup}. Context: start_error. Reason: {{badmatch,{error,[{{"dev-etcd.meross.dev.vpc",2379},{shutdown,ehostunreach}}]}},[{ekka_cluster_etcd,init,1,[{file,"ekka_cluster_etcd.erl"},{line,357}]},{gen_server,init_it,2,[{file,"gen_server.erl"},{line,851}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,814}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,240}]}]}. Offender: id=ekka_cluster_etcd,pid=undefined.
2023-09-07T02:09:07.466098+00:00 [error] crasher: initial call: ekka_cluster_etcd:init/1, pid: <0.2244.0>, registered_name: [], error: {{badmatch,{error,[{{"dev-etcd.meross.dev.vpc",2379},{shutdown,ehostunreach}}]}},[{ekka_cluster_etcd,init,1,[{file,"ekka_cluster_etcd.erl"},{line,357}]},{gen_server,init_it,2,[{file,"gen_server.erl"},{line,851}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,814}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,240}]}]}, ancestors: [ekka_cluster_sup,ekka_sup,<0.2241.0>], message_queue_len: 0, messages: [], links: [<0.2243.0>], dictionary: [], trap_exit: true, status: running, heap_size: 610, stack_size: 28, reductions: 289; neighbours: []

让他能在etcd恢复时重连成功。

9月11号后的日志。只有201连接etcd不正常。