问题背景
周一上班，首先向同事了解了一下上周的测试情况，被告知在多实例场景下 MySQL Server hang 住，无法测试下去，原生版本不存在这个问题，而新版本上出现了这个问题，不禁心头一颤，心中不禁感到奇怪，还好现场环境还在，为排查问题提供了一个好的环境，随即便投入到紧张的问题排查过程当中。问题实例表现如下：
首先，通过 pstack 工具获取当前问题实例的堆栈信息以便后面具体线程的查找 lock_word= 0}!!!，即 Thread 446 在等待一个空闲的 mutex，而这个Mutex也确实被等待，由于我们的版本为 Release 版本，所以很多有用的信息没有办法得到，而若用 debug 版本跑则很难重现问题，log_flush_order_mutex 的定义如下：
由以上的分析可以得出 问题二 的答案：
只有两个线程和log_sys->log_flush_order_mutex有关，其中一个是 Thread 446 线程， 另外一个则是最近一次调用 log_flush_order_mutex_exit() 的线程； 现有线程中某个线程在释放log_sys->log_flush_order_mutex的过程中没有唤醒 Thread 446，导致Thread 446 hang 并造成其它线程不能获得 log_sys->mutex，进而造成实例不可用； log_sys->log_flush_order_mutex 没有被任何线程获得。 3.问题三：绝处逢生
由问题二的分析过程可知 log_sys->log_flush_order_mutex 没有被任何线程获得，可是为什么 Thread 446 没有被唤醒呢，信号丢失还是程序问题？如果是信号丢失，为什么可以稳定复现？官方的bug list 列表中是没有类似的 Bug的，搜了一下社区，发现可用信息很少，这个时候分析好像陷入了死胡同，心里压力开始无形中变大……好像没有办法，但是任何问题都是有原因的，找到了原因，也就是有解的了……再一次将注意力移到了 Thread 446 的堆栈中，然后查看了函数：
由问题二的分析过程可以得出某线程在 log_flush_order_mutex_exit 的退出过程没有将 Thread 446 唤醒，那么就顺着这个函数找，看它如何唤醒其它本程的，在没有办法的时候也只有这样一步一步的分析代码，希望有些收获，随着函数调用的不断深入，将目光定在了 mutex_exit_func 上, 函数中的注释引起了我的注意：
从上面的注释中可以得到两点信息：
由于 memory barrier 的存在，mutex_get_waiters
结合 log_sys->log_flush_order_mutex 的状态信息，实例 hang 住的整个过程如下：
关于 Memory barrier 的介绍可以参考 ：
Memory barrierhttp://name5566.com/4535.html
问题解决
既然知道了问题产生的原因，那么问题也就可以顺利解决了，有两种方法：
直接移除 log_get_lsn 在此处的判断，本身就是开发人员加的一些判断信息，为了定位 LSN 的异常而写的，用到的时候也Crash了，用处不大； 保留判断，将 log_get_lsn 修改为 log_peek_lsn, 后者会首先进行 try_lock，当发现上锁失败的时候会直接返回，而不进行判断，这种方法较优雅些； 经过修改之后的版本在测试过程中没有没有再复现此问题。
问题扩展
虽然问题解决了，但官方版本中肯定存在着这个问题，为什么 buglist 没有找到相关信息呢，于是在查看了最新代码，发现这个问题已经修复，修复方法为上面列的第二种方法，详细的 commit message 信息如下：
bug影响范围：MySQL 5.6.28 及之前的版本都有此问题。