MHA binlog Dump (GTID) zombie process cleanup

Master survives the state of the switch Masterha_master_switch--conf=/etc/masterha/app1.cnf--master_state=alive--new_master_host= 192.168.0.101--orig_master_is_new_slave--running_updates_limit=1000 An unexpected situation, the following error is reported:

View Source code:

Gets the executing process on the new master, which is the show processlist operation. and the obtained processlist information is analyzed and judged, if the new master currently exists Binlog dump or binlog dump gtid process, etc., you cannot switch.

SOURCE DBHELPER.PM Fragment

The reason for the error is that after the switch succeeded, the original master became slave, and the new slave on the Binlog dump Gtid thread did not stop, theoretically after the successful handover, due to the role of conversion, the original master into Slave,binlog dump  The Gtid process should stop running, why hasn't it been stopped? View the error log on the new master.

The connection is lost and the connection is lost, causing the slave not to receive the signal, so the process is not stopped.

This problem can be configured by the master-slave synchronous heartbeat detection time to trigger the master-slave detection in advance, so as to achieve slave Binlog dump Gtid process early stop. The system default master-slave detection time is 3600S. Configure the following to perform a stop slave on a slave that may become master;
Change Master to Master_heartbeat_period = 10;
Set global slave_net_timeout = 25;
Start slave; perform change master to Master_heartbeat_period = 10 at the current Lord;
Set global slave_net_timeout = 25; Can be directly configured in the configuration file Slave_net_timeout = 25 again manually cut the master again when the Binlog dump Gtid process was quickly cleaned up, will not error.

MHA binlog Dump (GTID) zombie process cleanup