本文关键字：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 的技术内容，你们还有什么想知道的吗？赶紧留言告诉小编吧！
