前两天碰到一个1205（ER_LOCK_WAIT_TIMEOUT）的错误，弄了半天终于找到原因，把握道理+细心才干找到罪归祸首。下面我给大师分享下这个题目的解析处理惩罚过程，对大师有所帮助。接到slave error告警后，看到现场是如许的：slave重做binlog因为锁超时中断，报HA_ERR_LOCK_WAIT_TIMEOUT错误。
    超时，easy啊，心想估计是有大事务长久持有锁，导致其他事务超时守候。然则这个库是只读的备库，不成能有写事务，经由过程show processlist号令也确切没有发明写事务，倒是有一个大查询任务。当时感觉MVCC查询不上锁啊，直接疏忽。我测验测验从头start slave，发明没过几秒钟，错误依然呈现，并且_Master_Log_Pos没有变更，这申明同样的事务测验测验写错误，依然被堵住，导致锁超时守候了。这必然是事务持有锁导致锁超时，但机械上除了查询，啥也木有。隔离级别，确认下隔离级别，固然临盆景象中机械都是RC（读提交）模式，但也不打消这种可能。但成果再次让我绝望，事务隔离级别是读提交。

    会不会是存储引擎的题目，我又验证了一把，表是innodb存储引擎，读不存在说是上表锁的景象。无语了，莫非innodb的MVCC，读在某些景象下也上锁？这岂不是与读不上锁上违背吗？持续排查题目，查看锁守候景象：

这申明白实有事务堵住了更新。持续，

    从图中可以看到，blocking_query确切是语句，靠，莫非真是它上锁了，上的什么锁呢？

    可以看到一个读锁和一个写锁，这说了然，查询的确是上了记录的读锁，锁应当都是在innodb层面加的。到底为啥会上读锁呢？

    答案揭晓了，可以看到RUNNING的事务隔离级别是SERIALIZABLE，串行化隔离级别导致读上锁，进而梗阻复制无法进行下去。

    这个例子其实很简单，经由过程这个例子可以看到，information_schema下面的几张表太首要了，露出了很多信息，便利我们排查题目。同时排查题目时，必然要坚信道理，并且细心，题目总会内情毕露。