Xtrabackup Unable to obtain lock. Please try again later.

野性酷女 2023-06-15 09:53 14阅读 0赞

使用Xtrabackup遇到以下错误：

191121 07:00:48 Waiting for query 81858758 (duration 2958 sec)
    191121 07:00:49 Unable to obtain lock. Please try again later.

这个错误主要跟innobackupex的ftwrl-wait-timeout有关，因为在备份脚本中设置了`ftwrl-wait-timeout=180`，备份失败是因为等待慢查询query 81858758超过了180秒，而自动退出。

那么ftwrl-wait-timeout这个参数到底是什么意思呢？看下官方的解释：

--ftwrl-wait-timeout=# 
                          This option specifies time in seconds that innobackupex
                          should wait for queries that would block FTWRL before
                          running it. If there are still such queries when the
                          timeout expires, innobackupex terminates with an error.
                          Default is 0, in which case innobackupex does not wait
                          for queries to complete and starts FTWRL immediately.

刚开始看的时候有点一头雾水，有点混淆的感觉。是因为一直以为flush table with read lock是在备份non-innodb表前直接执行的。  
也查了一圈网上的博客，都说的模棱两可，甚至有些错误地解释ftwrl-wait-timeout为flush table with read lock等待全局读锁的超时设置。

其实ftwrl-wait-timeout真正的解释是，在执行flush table with read lock前，等待慢查询结束的超时时间，这个超时时间是等待慢查询结束的时间，而不是等待全局锁的时间，因为在等待的期间，innobackupex根本就还没发起flush table with read lock。

为什么有这种逻辑呢？那是因为如果已经有慢查询存在的情况，再直接执行flush table with read lock，那么在慢查询结束之前，innobackupex发起的会话必然会被堵塞，更严重的是，后续的所有会话，也会被innobackupex的会话所堵塞。  
这时kill掉innobackupex发起的会话仍然无法解决堵塞的问题，而是要慢查询结束或者把它kill掉。

那么针对这种情况，xtrabackup在执行ftwrl之前，会检查是否有慢查询在执行，如果已经有慢查询在执行了，那么xtrabackup就不执行ftwrl，而是等到慢查询结束的那一刻，才发起语句执行。  
那么，什么才是xtrabackup认为的慢查询呢？由ftwrl-wait-threshold控制，默认是60秒，即已经执行60秒以上的查询。

那么对于短于ftwrl-wait-threshold的查询呢？xtrabackup会马上发起ftwrl，但是如果短查询其实就是一个隐藏的慢查询呢？  
这时有kill-long-queries-timeout和kill-long-query-type来处理，kill-long-queries-timeout表示在发起ftwrl后等待全局读锁的时间，时间一过，就把堵塞它的查询kill掉，而kill-long-query-type控制可以kill掉的查询类型。