Analyzing MySQL Group Replication Node Failure Handling with Wireshark

In a MySQL Group Replication (MGR) cluster, the article investigates how MySQL schedules and removes a node that exits unexpectedly, and when the failed node is expelled from the cluster.

The experiment uses three virtual machines to create an MGR cluster running MySQL 5.7.20, a low version chosen to observe clear MGR behavior.

Because Wireshark does not natively support the MGR protocol, a custom Wireshark dissector plugin is downloaded from GitHub and installed.

Packet capture is performed on the primary node (test-mgr-1). After capturing, the node test-mgr-3 is deliberately terminated, and the capture file test-mgr-1.cap is opened in Wireshark using the MGR protocol dissector.

A new column displaying the MGR message type ( mgr.app_data.body.cargo_type ) is added to the packet list, allowing the identification of specific MGR messages.

Filtering the capture reveals three messages sent from the primary (10.186.61.45) to another alive node (10.186.61.71): a view_msg , a remove_node_type , and another view_msg .

The first view_msg shows the cluster view where node 1 and node 2 are online while node 3 is offline.

The remove_node_type message notifies other nodes that the offline node (node 3) should be removed from the cluster.

One second later, the second view_msg presents an updated view containing only the two remaining nodes.

Through this packet analysis, the article demonstrates that after a node crashes, the primary quickly disseminates the offline status, removes the node from the cluster, and informs all members, and that the custom Wireshark plugin aids in understanding MGR scheduling behavior.