背景

在MySQL中Slave相关操作一直存在一把大锁——LOCK_active_mi (5.5及之前版本，以及MariaDB)，或LOCK_msp_map（5.6及之后的版本）。 在Slave操作中大家可能经常会遇到如下懵逼的操作：

  1. 线程1：STOP SLAVE；有事务要回滚，一直不结束，然后LOCK_active_mi一直被这个线程持有
  2. 线程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通道的操作到底有哪些是真的互斥。

  1. 并发读写同一个通道的运行状态： 例如 mi->running，mi->info_thd 等，已有mi->run_lock保护IO线程，mi->rli->run_lock保护SQL线程。

  2. 并发读写同一个通道的执行数据： 例如 mi->master_log_pos，mi->rpl_filter 等，已有mi->data_lock保护IO线程，mi->rli->data_lock保护SQL线程。

  3. 并发读写同一个通道的错误码和错误消息： 例如 mi->last_error 等，已有mi->err_lock保护IO线程，mi->rli->err_lock保护SQL线程。

  4. 对于多源复制，增减通道： 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的并发性的：

  1. 每当有线程正在访问Page时，将计数器（bpage->io_fix）加一，就把这个Page Pin在内存中了。
  2. LRU淘汰Page时，看到io_fix还不是0，就不能从内存中清理，因为还有人在访问，必须等到0才能清除。
  3. 对Page内容的操作，有Latch来保证，避免同时有人修改页面。

因此我们也可以在每个Master_info中加一个计数器（mi->users），有线程要使用mi，就将计数器加一，不用了就减一，以此来代替加锁放锁，再用一个专门的锁（sleep_lock）来保护计数器就可以了。

加锁操作成了：

  1. void Master_info::use()
  2. {
  3.   mysql_mutex_lock(&sleep_lock);
  4.   users++;
  5.   mysql_mutex_unlock(&sleep_lock);
  6. }

放锁操作成了：

  1. void Master_info::release()
  2. {
  3.   mysql_mutex_lock(&sleep_lock);
  4.   if (!--users && killed)
  5.     mysql_cond_signal(&sleep_cond);
  6.   mysql_mutex_unlock(&sleep_lock);
  7.   DBUG_VOID_RETURN;
  9. }

每次放锁时发一个信号量，让remove_mi操作能收到信号量后再执行删除Master_info的操作。

然后原本需要LOCK_msr_map保护的Master_info操作，可以缩小范围，只需要在取出mi时拿锁就可以了。

  1. Master_info *get_master_info(const char *connection_name)
  2. {
  3.   Master_info *mi;
  4.   DBUG_ENTER("get_master_info");
  5.   /* Protect against inserts into msr_map */
  6.   mysql_mutex_lock(&LOCK_msr_map);
  7.   if ((mi= msr_map.get_mi(connection_name)))
  9.     mi->use();
  10.   mysql_mutex_unlock(&LOCK_msr_map);
  11.   DBUG_RETURN(mi);
  12. }

再把原来需要get_mi调用的地方，全部修改为get_master_info这个调用，就可以删掉其mysql_mutex_lock(&LOCK_msr_map)加锁保护了，放锁的mysql_mutex_unlock(&LOCK_msr_map)语句全部改成mi->release()即可。这样就不存在全局锁定了。

比如启动一个通道的复制：

  1. if ((mi= get_master_info(lex->mi.channel)))
  2.   {    
  3.     res= start_slave(thd, mi, 1 /*net report */); 
  4.     mi->release();
  5. }

完全不需要 mysql_mutex_lock(&LOCK_msr_map)和mysql_mutex_unlock(&LOCK_msr_map)来包住start_slave了对不对！

但这种修改就带来了另一个问题，要删除一个Master_info的时候，可能还有线程在使用这个mi。 因此在析构函数中需要增加一个等待，让这个mi的所有调用都释放了再清理这个mi。 有了计数器这个也很容易做到，每当收到计数器减一的信号时，看一下是不是计数器到0了，到0了就说明所有使用者全部释放了，就可以正常删除了。

  1. void Master_info::wait_until_free()
  2. {
  3.   mysql_mutex_lock(&sleep_lock);
  4.   killed= 1;
  5.   while (users)
  6.     mysql_cond_wait(&sleep_cond, &sleep_lock);
  7.   mysql_mutex_unlock(&sleep_lock);
  8. }

效果

这样改进以后，我们再来看最开始这个典型的案例：

  1. STOP SLAVE执行卡住，那么会导致这个mi或者所有mi的计数器加一。
  2. SHOW SLAVE STATUS执行，在这个mi或者所有mi的计数器加一。 并不涉及到相互锁定，只是此时无法删除通道而已，这也是合理的。两个线程都能愉快的执行自己的任务。

补丁我们会在之后的AliSQL开源版本中开源，敬请期待。