背景
在MySQL中Slave相关操作一直存在一把大锁——LOCK_active_mi (5.5及之前版本，以及MariaDB)，或LOCK_msp_map（5.6及之后的版本）。
在Slave操作中大家可能经常会遇到如下懵逼的操作：
- 线程1：STOP SLAVE；有事务要回滚，一直不结束，然后LOCK_active_mi一直被这个线程持有
- 线程2：SHOW SLAVE STATUS；拿不到LOCK_active_mi，无法执行。
SHOW SLAVE STATUS 经常作为监控脚本的语句被自动执行，然后就不停地被卡住，线程堆积，直到 too many connections。
等到了5.6引入了多源复制之后，这个问题就更严重了，LOCK_msr_map需要在访问任何通道时都被持有，因此操作两个不同的通道也可能冲突。
Percona曾经推出了SHOW SLAVE STATUS NO_BLOCK这样的语法，不加锁查看复制状态，但是，毕竟这不是根治之法，一方面查看的数据并不一定对，还可能Crash（例如查看过程中通道被删除了），并且需要专门的语法。
特别是5.6还支持了多线程复制，IO THREAD可以多个（多通道），SQL THREAD可以并行（并行复制），这种情况下，LOCK_msr_map这么大一把锁就更加显得格格不入了。
解决思路
我们先来分析一下，对各个Slave通道的操作到底有哪些是真的互斥。
-
并发读写同一个通道的运行状态：
例如 mi->running，mi->info_thd 等，已有mi->run_lock保护IO线程，mi->rli->run_lock保护SQL线程。 -
并发读写同一个通道的执行数据：
例如 mi->master_log_pos，mi->rpl_filter 等，已有mi->data_lock保护IO线程，mi->rli->data_lock保护SQL线程。 -
并发读写同一个通道的错误码和错误消息：
例如 mi->last_error 等，已有mi->err_lock保护IO线程，mi->rli->err_lock保护SQL线程。 -
对于多源复制，增减通道：
msr_map结构的增删改查需要保护，否则可能在遍历所有通道时有通道增加或删除，那遍历结果就不对了。这里真的需要LOCK_msr_map保护。
可见，除了msr_map的操作真的需要全局互斥以外，其他的操作其实都有Master_info内的锁可以保护，在mi内部解决矛盾就可以，根本无需全局锁。
MySQL 5.7 给了一个改进方案，是将LOCK_msr_map从mysql_mutex_t（pthread_mutex_t）改成了Checkable_rwlock。这个方案可以解决部分只读操作时可以相互并发，但是并没有解决LOCK_msr_map保护范围太广的问题。上面我们给出的STOP SLAVE卡住（wr_lock）和SHOW SLAVE STATUS执行互斥的问题就没有解决。
为了彻底解决这个问题，我们可以参考InnoDB怎么保证Buffer Pool中Page的并发性的：
- 每当有线程正在访问Page时，将计数器（bpage->io_fix）加一，就把这个Page Pin在内存中了。
- LRU淘汰Page时，看到io_fix还不是0，就不能从内存中清理，因为还有人在访问，必须等到0才能清除。
- 对Page内容的操作，有Latch来保证，避免同时有人修改页面。
因此我们也可以在每个Master_info中加一个计数器（mi->users），有线程要使用mi，就将计数器加一，不用了就减一，以此来代替加锁放锁，再用一个专门的锁（sleep_lock）来保护计数器就可以了。
加锁操作成了：
void Master_info::use()
{
mysql_mutex_lock(&sleep_lock);
users++;
mysql_mutex_unlock(&sleep_lock);
}
AI 代码解读
放锁操作成了：
void Master_info::release()
{
mysql_mutex_lock(&sleep_lock);
if (!--users && killed)
mysql_cond_signal(&sleep_cond);
mysql_mutex_unlock(&sleep_lock);
DBUG_VOID_RETURN;
}
AI 代码解读
每次放锁时发一个信号量，让remove_mi操作能收到信号量后再执行删除Master_info的操作。
然后原本需要LOCK_msr_map保护的Master_info操作，可以缩小范围，只需要在取出mi时拿锁就可以了。
Master_info *get_master_info(const char *connection_name)
{
Master_info *mi;
DBUG_ENTER("get_master_info");
/* Protect against inserts into msr_map */
mysql_mutex_lock(&LOCK_msr_map);
if ((mi= msr_map.get_mi(connection_name)))
mi->use();
mysql_mutex_unlock(&LOCK_msr_map);
DBUG_RETURN(mi);
}
AI 代码解读
再把原来需要get_mi调用的地方，全部修改为get_master_info这个调用，就可以删掉其mysql_mutex_lock(&LOCK_msr_map)加锁保护了，放锁的mysql_mutex_unlock(&LOCK_msr_map)语句全部改成mi->release()即可。这样就不存在全局锁定了。
比如启动一个通道的复制：
if ((mi= get_master_info(lex->mi.channel)))
{
res= start_slave(thd, mi, 1 /*net report */);
mi->release();
}
AI 代码解读
完全不需要 mysql_mutex_lock(&LOCK_msr_map)和mysql_mutex_unlock(&LOCK_msr_map)来包住start_slave了对不对！
但这种修改就带来了另一个问题，要删除一个Master_info的时候，可能还有线程在使用这个mi。
因此在析构函数中需要增加一个等待，让这个mi的所有调用都释放了再清理这个mi。
有了计数器这个也很容易做到，每当收到计数器减一的信号时，看一下是不是计数器到0了，到0了就说明所有使用者全部释放了，就可以正常删除了。
void Master_info::wait_until_free()
{
mysql_mutex_lock(&sleep_lock);
killed= 1;
while (users)
mysql_cond_wait(&sleep_cond, &sleep_lock);
mysql_mutex_unlock(&sleep_lock);
}
AI 代码解读
效果
这样改进以后，我们再来看最开始这个典型的案例：
- STOP SLAVE执行卡住，那么会导致这个mi或者所有mi的计数器加一。
- SHOW SLAVE STATUS执行，在这个mi或者所有mi的计数器加一。
并不涉及到相互锁定，只是此时无法删除通道而已，这也是合理的。两个线程都能愉快的执行自己的任务。
补丁我们会在之后的AliSQL开源版本中开源，敬请期待。
