stop slave卡住

雨点打透心脏的1/2处 2022-12-10 14:49 140阅读 0赞

在MySQL主从架构集群中，如果主库发生故障，需要立刻提升一个从库为新主库。在这个过程中，有一个操作是在从库上执行`stop slave`停止复制的操作，一般情况下，会非常顺利。  
但也有特殊情况下，会遇到`stop slave`被卡住的问题。

这样，给故障恢复过程造成了一定的困扰。

本文模拟一种`stop slave`被卡住的情况。

MySQL版本: `5.7.27-log`

# 1.模拟过程 #

首先准备一个主从集群，具体过程参见[MySQL主从集群搭建][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`:

`stop slave` 一直处于`Killing slave`状态。

前面已经提到，在从库上加锁后，必须在主库上写入数据，问题才会复现，因此推测，  
问题原因可能是，`read lock`与 `SQL thread`死锁造成的。

# 3.其他被卡住的情况 #

在网上搜到一种情况是，  
执行`flushs tables with read lock`以及`show slave status`会有可能和SQL Thread形成死锁，导致SQL Thread一直被卡住。这样，`stop slave`就被卡住了。

这种情况跟 [\#70307][70307] bug 有关。

# 4.参考 #

[MySQL 5.6的 \#70307bug引发的故障][MySQL 5.6_ _70307bug]

[LOCK TABLES and UNLOCK TABLES Statements][]

[对Mysql Bug \#70307 的学习][Mysql Bug _70307]

[对Mysql Bug \#70307 的再学习][Mysql Bug _70307 1]

[MySQL]: https://blog.csdn.net/lanyang123456/article/details/104103520
[70307]: https://bugs.mysql.com/bug.php?id=70307
[MySQL 5.6_ _70307bug]: https://www.cnblogs.com/gomysql/p/7284717.html
[LOCK TABLES and UNLOCK TABLES Statements]: https://dev.mysql.com/doc/refman/5.7/en/lock-tables.html
[Mysql Bug _70307]: http://ikarishinjieva.github.io/blog/blog/2013/10/25/study-mysql-bug-70307/
[Mysql Bug _70307 1]: http://ikarishinjieva.github.io/blog/blog/2014/04/01/study-mysql-bug-70307-2/