对Mysql bug #70307 的再学习
Tue, Apr 1, 2014之前对bug #70307有过学习, 苦于阿兹海默状态, 又花了半天在mysql 5.5.33上探查这个场景的原因…
简单记录一下
现象
mysql进行主从复制, 从机上FLUSH TABLES WITH READ LOCK后, 进行STOP SLAVE, 一定概率下 SHOW SLAVE STATUS卡住
重现步骤
| master | slave client 1 | slave client 2 |
|---|---|---|
| - | STOP SLAVE IO_THREAD | - |
| CREATE TABLE TEST.TEST … | - | - |
| - | FLUSH TABLES WITH READ LOCK | - |
| - | START SLAVE IO_THREAD | - |
| - | - | STOP SLAVE |
| - | SHOW SLAVE STATUS | - |
其中, START/STOP SLAVE IO_THREAD是为了在FLUSH TABLES WITH READ LOCK时造成slave io_thread有未提交数据
死锁原因
FLUSH TABLES WITH READ LOCK会阻塞IO_THREAD提交数据STOP SLAVE会等待IO_THREAD结束 (mi->stop_cond), 即STOP SLAVE间接被FLUSH TABLES WITH READ LOCK阻塞STOP SLAVE在被阻塞前, 持有了LOCK_active_mi, 独占了master_infoSHOW SLAVE STATUS会申请锁LOCK_active_mi, 被STOP SLAVE阻塞- 如果
SHOW SLAVE STATUS是由之前FLUSH TABLES WITH READ LOCK的slave client 1发出的, 那逻辑上相当于自己在等待自己释放资源 - 从另外的client上
UNLOCK TABLES也解不开