Description:
When slave successfully ran "STOP SLAVE", the Binlog Dump thread on master is expected to exit, which is at least the behavior in 5.1 and earlier versions of 5.5, like 5.5.29. However, on 5.6.28, the dump thread is left around and only exit when the same slave(same server uuid) reconnects. This behavior is also observed in 5.5.48. There is another bug report on zombie dump thread which is related but different. https://bugs.mysql.com/bug.php?id=77195
Here is an illustration on a sandbox:
Server version: 5.6.28-log MySQL Community Server (GPL)
node2 [localhost] {msandbox} ((none)) > show processlist;
+----+-------------+-----------------+------+-------------+------+-----------------------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-------------+-----------------+------+-------------+------+-----------------------------------------------------------------------------+------------------+
| 7 | rsandbox | localhost:55593 | NULL | Binlog Dump | 293 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL |
| 9 | system user | | NULL | Connect | 293 | Waiting for master to send event | NULL |
| 10 | system user | | NULL | Connect | 292 | Slave has read all relay log; waiting for the slave I/O thread to update it | NULL |
| 11 | msandbox | localhost | NULL | Query | 0 | init | show processlist |
+----+-------------+-----------------+------+-------------+------+-----------------------------------------------------------------------------+------------------+
node1 [localhost] {msandbox} ((none)) > stop slave;
node2 [localhost] {msandbox} ((none)) > show processlist;
+----+-------------+-----------------+------+-------------+------+-----------------------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-------------+-----------------+------+-------------+------+-----------------------------------------------------------------------------+------------------+
| 7 | rsandbox | localhost:55593 | NULL | Binlog Dump | 321 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL |
| 9 | system user | | NULL | Connect | 321 | Waiting for master to send event | NULL |
| 10 | system user | | NULL | Connect | 320 | Slave has read all relay log; waiting for the slave I/O thread to update it | NULL |
| 11 | msandbox | localhost | NULL | Query | 0 | init | show processlist |
+----+-------------+-----------------+------+-------------+------+-----------------------------------------------------------------------------+------------------+
4 rows in set (0.00 sec)
node1 [localhost] {msandbox} ((none)) > start slave;
node2 [localhost] {msandbox} ((none)) > show processlist;
+----+-------------+-----------------+------+-------------+------+-----------------------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-------------+-----------------+------+-------------+------+-----------------------------------------------------------------------------+------------------+
| 9 | system user | | NULL | Connect | 346 | Waiting for master to send event | NULL |
| 10 | system user | | NULL | Connect | 345 | Slave has read all relay log; waiting for the slave I/O thread to update it | NULL |
| 11 | msandbox | localhost | NULL | Query | 0 | init | show processlist |
| 12 | rsandbox | localhost:55595 | NULL | Binlog Dump | 3 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL |
+----+-------------+-----------------+------+-------------+------+-----------------------------------------------------------------------------+------------------+
How to repeat:
Example in the description.
Suggested fix:
I didn't find in the Documentation that refer to this dump thread behavior change. If this is by design, it would need some documentation on it, as well as why it is preferred to leave the dump thread around. Otherwise, the dump thread should exit when replication stops.
