在MySQL主从架构集群中，如果主库发生故障，需要立刻提升一个从库为新主库。在这个过程中，有一个操作是在从库上执行stop slave停止复制的操作，一般情况下，会非常顺利。
但也有特殊情况下，会遇到stop slave被卡住的问题。
这样，给故障恢复过程造成了一定的困扰。
本文模拟一种stop slave被卡住的情况。
MySQL版本: 5.7.27-log
1.模拟过程
首先准备一个主从集群，具体过程参见MySQL主从集群搭建。
1.1.主库数据准备
mysql> create database app;
Query OK, 1 row affected (0.01 sec)
mysql>
CREATE TABLE `test` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`service_group_name` varchar(100) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
1.2 从库加读锁
首先保证从库复制正常，start slave已开启复制。
在从库上打开终端1，对数据表test加读锁：
mysql> lock tables app.test read;
Query OK, 0 rows affected (0.00 sec)
mysql>
1.3 主库写入数据
在主库上写入一条数据：
mysql> insert into test(service_group_name) values('abc');
Query OK, 1 row affected (0.01 sec)
这个步骤是必须的，否则无法复现卡住问题。
1.4 从库 stop slave
在从库上，打开另一个终端2，执行stop slave，被卡住：
mysql> stop slave;
而且，
从库终端1上，执行解锁操作unlock tables;。
从库终端2上被卡住的命令会立刻返回。
2.原因
在从库上执行show processlist:
mysql> show processlist;
+----+-------------+-----------+------+---------+------+----------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-------------+-----------+------+---------+------+----------------------------------+------------------+
| 2 | root | localhost | app | Query | 0 | starting | show processlist |
| 15 | root | localhost | NULL | Query | 66 | Killing slave | stop slave |
| 27 | system user | | NULL | Connect | 2589 | Waiting for master to send event | NULL |
| 28 | system user | | NULL | Connect | 73 | Waiting for table metadata lock | NULL |
+----+-------------+-----------+------+---------+------+----------------------------------+------------------+
4 rows in set (0.00 sec)
stop slave 一直处于Killing slave状态。
前面已经提到，在从库上加锁后，必须在主库上写入数据，问题才会复现，因此推测，
问题原因可能是，read lock与 SQL thread死锁造成的。
3.其他被卡住的情况
在网上搜到一种情况是，
执行flushs tables with read lock以及show slave status会有可能和SQL Thread形成死锁，导致SQL Thread一直被卡住。这样，stop slave就被卡住了。
这种情况跟 #70307 bug 有关。