【转】XtraBackup之踩过的坑

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。

What’s the problem with FTWRL anyway?

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:

1. It first invalidates the Query Cache.
2. It then waits for all in-flight updates to complete and at the same time it blocks all incoming updates. This is one problem for busy servers.
3. It then closes all open tables (the 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.
4. Finally, it blocks COMMITs.

1.它首先使查询缓存无效。
2.然后，等待所有更新完成，并在同一时间，它阻止所有的更新。这对于繁忙的服务器是一个问题。
3.然后，它关闭所有打开的表（冲洗表）并且从表中的高速缓存刷出。这也是当FTWRL必须等待所有的SELECT查询完成。这是另一个更大的问题为繁忙的服务器，因为等待恰好发生这将堵塞所有的更新。更糟的是，服务器在这个阶段基本上是离线状态，因为即使进入的SELECT查询将被封锁。
4.最后，它会阻止事务提交。

 

Percona已经提供了解决方案（2.1版本开始）：

设置一个超时时间，避免无限期的等待。Xtrabackup提供了以下参数实现该功能：

--lock-wait-timeout=SECONDS, ，一旦Flush table with read lock被阻塞超过预定时间，则XtraBackup出错返回退出，该值默认为0，也就是说一旦阻塞，立即返回失败。
--lock-wait-query-type=all|update，该参数允许用户指定，哪类的SQL语句是需要Flush table with read lock等待的，同时用户可以通过--lock-wait-threshold=SECONDS设置等待的时间，如果不在query-type指定的类型范围内或者超过了wait-threshold指定的时间，XtraBackup均返回错误。如果指定update类型，则UPDATE/ALTER/REPLACE/INSERT 均会等待，ALL表示所有的SQL语句。

kill 其他阻塞线程
Kill掉所有阻塞Flush table with read lock的线程：
--kill-long-queries-timeout=SECONDS参数允许用户指定了超过该阈值时间的查询会被Kill，同时也允许用户指定Kill

SQL语句的类型。
--kill-long-query-type=all|select
默认值为ALL，如果选择Select，只有Select语句会被Kill，如果Flush table with read lock是被Update语句阻塞，则XtraBackup不会处理。

 

总结：

本次的复制延时故障由于从库在执行大查询，而且效率很差，刚好备份脚本执行，由于xtrabackup执行FLUSH TABLES WITH READ LOCK施加全局锁，导致锁等待。这时刚好从库执行INSERT操作，最后导致无法插入，等待全局锁，导致复制延时。

 

参考资料

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

 

Reference:

https://www.cnblogs.com/gomysql/p/4240565.html    XtraBackup之踩过的坑