第14问:在MGR集群里,一个节点异常退出后,会发生什么?

database

本文关键字:MGR、监控、Wireshark

问题

在一个 MGR 集群里,一个节点异常退出后,MySQL 会如何进行调度?异常的节点什么时候会被踢出集群?

实验

实验开始前,给大家分享一个小经验:选择合适的观测工具,如果没有,就创造一个。

我们先使用三台虚拟机,创建一个 MGR 的集群。MySQL 的版本是 5.7.20(之所以使用低版本的 MySQL,因为恐怕没有人能说清楚这个低版本的 MGR 的行为,不能扯淡只能观测)。

这次我们忽略这一操作步骤,只看一下创建好的集群:

检查一下谁是 Primary:

现在我们得选择一个观测工具了。我们知道 MGR 需要通过网络来相互沟通,对集群内的节点状况达成一致。通过抓包对 MGR 的行为进行分析,看上去是个不错的主意。

不过 Wireshark 并不支持分析 MGR 的网络协议,我们只能自己创造一个 Wireshark 的分析插件(dissector)。

此处我们忽略创造插件的过程,直接拿来用就可以了。

我们访问:

https://github.com/actiontech/wireshark-dissector-mysql-group-replicaiton/releases

下载 Wireshark 的安装包,并安装好:

我们在 MGR 的 Primary 节点(test-mgr-1)上抓包:

然后将一个节点(test-mgr-3)干掉:

我们用刚安装的 Wireshark 打开抓包的文件 test-mgr-1.cap,并使用 MGR 协议解开抓包:

效果如图:

我们现在为 Wireshark 的列表增加一列,将 MGR 的信息类型显示出来:

这一列的公式为:mgr.app_data.body.cargo_type

这样我们就能看到 MGR 的信息类型:

现在我们通过过滤公式,找到特定类型的 MGR 信息:

可以看到 MGR 的 Primary(10.186.61.45,也就是 test-mgr-1)向另一个存活节点(10.186.61.71,也就是 test-mgr-2)发送了三个信息,分别是 view_msg,remove_node_type,view_msg。我们仔细看看这三个包的详细信息:

第一个包,是 Primary 发出的 view 信息(view 是 MGR 的各个节点的状态),可以看到这个 view 的信息是:第一个节点在线,第二个节点在线,第三个节点离线。

第二个包是删除节点的通知,Primary 通知其他节点,将删除离线的节点三。

第三个包是一秒之后发送的,Primary 通知其他节点新的 view 是什么样的:新的 view 只有两个节点了。

通过抓包,我们看到了 MGR 各个节点间的信息交换,借此理解 MGR 节点间的调度行为。

在一个节点崩溃后,Primary 节点很快就向全员更新了某节点离线的信息。然后将其踢出集群,并将决定通知全员。

希望我们创造的这个 Wireshark 插件,可以帮助大家理解 MGR 的调度行为,也欢迎大家提需求或缺陷。


关于 MySQL 的技术内容,你们还有什么想知道的吗?赶紧留言告诉小编吧!

以上是 第14问:在MGR集群里,一个节点异常退出后,会发生什么? 的全部内容, 来源链接: utcz.com/z/534424.html

回到顶部