标签：
xtrabackup相信目前使用已经非常广泛了，备份innodb表的首选工具，但是其中还是有点小坑，虽然发生的概率不大，但是我还是踩坑了。关于xtrabackup的详细参考请查阅官方文档http://www.percona.com/doc/percona-xtrabackup/2.2/intro.html
突然收到报警，说从库延时，登录服务器执行show full processlist查看，发现有如下状态（自己模拟的，和当时线上情况一样）：
可以看见这里的INSERT语句卡住了，在等待一个全局锁，所以导致从库延时。那么问题来了。。。。。为什么有一个全局锁，FLUSH TABLES WITH READ LOCK。后来发现是刚不久在从库加了一个备份脚本，备份工具采用的是Percona的xtrabackup工具。这个工具在拷贝完文件以后需要执行FLUSH TABLES WITH READ LOCK。如下图：
由于需要执行FLUSH TABLES WITH READ LOCK (以下用FTWRL缩写代替)来获取全局GLOBAL的MDL锁，因此可以看到"wait for global read lock"之类的信息。如果备库存在大查询，或者复制线程正在执行比较漫长的DDL，并且FTWRL被block住，那么随后的QUERY都会被block住，导致业务不可用引发故障。
刚好在percona博客看到一篇文章，里面大概是这样说FTWRL。
A lot has been written on what FLUSH TABLES WITH READ LOCK really does. Here’s yet another walk-through in a bit more detail than described elsewhere:
FLUSH part) and expels them from the table cache. This is also whenFTWRL has to wait for all SELECT queries to complete. And this is another, even bigger problem for busy servers, because that wait happens to occur with all updates blocked. What’s even worse, the server at this stage is essentially offline, because even incoming SELECT queries will get blocked.1.它首先使查询缓存无效。
2.然后，等待所有更新完成，并在同一时间，它阻止所有的更新。这对于繁忙的服务器是一个问题。
3.然后，它关闭所有打开的表（冲洗表）并且从表中的高速缓存刷出。这也是当FTWRL必须等待所有的SELECT查询完成。这是另一个更大的问题为繁忙的服务器，因为等待恰好发生这将堵塞所有的更新。更糟的是，服务器在这个阶段基本上是离线状态，因为即使进入的SELECT查询将被封锁。
4.最后，它会阻止事务提交。
总结：
本次的复制延时故障由于从库在执行大查询，而且效率很差，刚好备份脚本执行，由于xtrabackup执行FLUSH TABLES WITH READ LOCK施加全局锁，导致锁等待。这时刚好从库执行INSERT操作，最后导致无法插入，等待全局锁，导致复制延时。这种情况Percona和Facebook都有相应的解决方案。最后xtrabackup从2.1版本开始，有参数预防类似的事情发生，感兴趣的同学自己查询xtrabackup官方文档。
参考资料
http://m.csdn.net/article/2015-01-20/2823634
http://www.percona.com/blog/2014/03/11/introducing-backup-locks-percona-server-2/
http://www.percona.com/blog/2010/04/24/how-fast-is-flush-tables-with-read-lock/
http://www.percona.com/doc/percona-xtrabackup/2.2/innobackupex/improved_ftwrl.html
标签：
原文地址：http://www.cnblogs.com/gomysql/p/4240565.html
