MySQL备份失败的问题分析和处理是怎样的

共计 3771 个字符，预计需要花费 10 分钟才能阅读完成。

本篇文章为大家展示了 MySQL 备份失败的问题分析和处理是怎样的，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。

今天和同事一起处理了一个奇怪的 MySQL 空间异常问题，从这个问题的处理中可以找到一些问题处理的方式。

问题的背景是有一个实例的备份总是失败，在排查了多次之后，在保证 Slave 可用的情况先搁置了，刚好借着这几天的时间做了下收尾和梳理。

备份失败的报错提示信息是：

innobackupex: Error writing file  /tmp/xbtempevLQbf  (Errcode: 28 - No space left on device) xtrabackup: Error: write to logfile failed xtrabackup: Error: xtrabackup_copy_logfile() failed.

看起来多直白的问题，空间不足嘛，是不是空间配置的问题。

但是在本地进行模拟测试的时候，使用了如下的脚本开启本机测试。 

/usr/local/mysql_tools/percona-xtrabackup-2.4.8-Linux-x86_64/bin/innobackupex --defaults-file=/data/mysql_4308/my.cnf --user=xxxx --password=xxxx --socket=/data/mysql_4308/tmp/mysql.sock --stream=tar /data/xxxx/mysql/xxxx_4308/2020-02-11   /data/xxxx/mysql/xxxx_4308/2020-02-11.tar.gz

发现所在的 /tmp 目录却没有空间异常的情况，而相反是根目录的空间使用出现了异常, 这是测试中截取到的一个空间异常的截图。

而在抛出异常之后，备份失败，空间使用率马上恢复。

综合目前得到的信息，我的直观感觉是问题貌似和 /tmp 没有太直接的联系，那一定是在根目录的使用过程中的其他目录产生了异常。

于是我开始了第二次测试，这一次我着重关注根目录的整体使用，看看到底是哪个目录的使用异常了，但是尴尬的是，尽管做了脚本的快速采集，竟然没有发现在我们常见的目录下有空间异常。

332K ./home 411M ./lib 26M ./lib64 16K ./lost+found 4.0K ./media 4.0K ./misc 4.0K ./mnt 0 ./net 184M ./opt du: cannot access `./proc/40102/task/40102/fd/4 : No such file or directory du: cannot access `./proc/40102/task/40102/fdinfo/4 : No such file or directory du: cannot access `./proc/40102/fd/4 : No such file or directory du: cannot access `./proc/40102/fdinfo/4 : No such file or directory 0 ./proc 2.3G ./root 56K ./tmp 。。。

所以从目前的情况来看，应该是 /proc 相关的目录下的空间异常了。

事情到了这个时候，似乎可用的方式已经不多了。

我排查了脚本，排查了参数文件，整体来看没有和其他环境相比明显的问题，但是有一个细节引起了我的注意，那就是使用 top 的时候，看到这个实例的内存使用了 6G(服务器内存是 8G), 但是 buffer pool 的配置才是 3G 左右，这是一个从库环境，也没有应用连接，所以也不大可能存在太多的连接资源消耗，所以综合来看，应该是和服务器的内存异常有关。

这个时候尝试了在线 resize, 发现已经没有收缩的空间了。因为是从库服务，于是我开始重启从库的服务。

但是意外的是重启数据库的时候卡住了，大概过了有 2 分钟，只是看到一些输出的小数点，大概输出了两行，还是没有反应，查看后台日志没有任何输出，于是我开始尝试 plan B，准备 Kill 进程重启服务。

这一次 kill 操作生效了，过一会服务启动起来了。但是报出了从库复制异常。

 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log:  The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.  。。。 Master_Server_Id: 190 Master_UUID: 570dcd0e-f6d0-11e8-adc3-005056b7e95f 。。。 Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: 200211 14:20:57 Retrieved_Gtid_Set: 570dcd0e-f6d0-11e8-adc3-005056b7e95f:821211986-2157277214 Executed_Gtid_Set: 570dcd0e-f6d0-11e8-adc3-005056b7e95f:1-820070317:821211986-2157277214

这个错误的信息是比较明显了，是主库的 binlog 被 purge 掉了，导致在从库去复制应用的时候失败了。

为什么会有这么奇怪的一个问题呢，因为主库的 binlog 默认还是保留了一些天数，不至于把 1 个小时前的 binlog 删除。

关于 GTID 的一些变量值如下:

Retrieved_Gtid_Set: 570dcd0e-f6d0-11e8-adc3-005056b7e95f:821211986-2157277214

Executed_Gtid_Set: 570dcd0e-f6d0-11e8-adc3-005056b7e95f:1-820070317:821211986-2157277214

gtid_purged     ：570dcd0e-f6d0-11e8-adc3-005056b7e95f:1-820070317:821211986-2131381624

Master 端的 GTID_Purged 为：

gtid_purged     ：570dcd0e-f6d0-11e8-adc3-005056b7e95f:1-2089314252

综合这些信息来看，Slave 端的 GTID 和主库没有完整的衔接起来，也就意味着在之前对这个 Slave 做过一些操作，导致 GTID 在 Master 和 Slave 端产生了一些偏差。

而这个遗漏的变更部分 570dcd0e-f6d0-11e8-adc3-005056b7e95f:821211986 保守来估计也是 1 个月以前了，binlog 是肯定没有保留的。

我们在此先暂时修复这个复制问题。

停止 Slave 没想到又出问题了，一个看似简单的 stop Slave 操作竟然持续了 1 分多钟。

stop slave;

Query OK, 0 rows affected (1 min 1.99 sec)

尝试减小 Buffer pool 配置，重启，stop slave, 这个操作依然很慢，所以可以在这个方向上排除延迟的问题和 Buffer Pool 关系不大，而相对和 GTID 的关系更大一些。

Slave 端修复步骤如下：

reset master; stop slave; reset slave all; SET @@GLOBAL.GTID_PURGED= 570dcd0e-f6d0-11e8-adc3-005056b7e95f:1-2157277214  CHANGE MASTER TO MASTER_USER= dba_repl , MASTER_PASSWORD= xxxx  , MASTER_HOST= xxxxx ,MASTER_PORT=4308,MASTER_AUTO_POSITION = 1;

其中 GTID_PURGED 的配置是关键。

修复后，Slave 端的延迟问题就解决了，而再次尝试重新备份，在根目录竟然没有了空间消耗。

这个过程中主要是要快速解决问题，有些步骤的日志抓取的不够丰富和细致，从问题的分析来说，还是缺少了一些更有说服力的东西，对于问题的原因，本质上还是不合理的问题（比如 bug 或者配置异常等）导致了不合理的现象。

在这一块还是可以借鉴的是分析的整体思路，而不是这个问题本身。 

上述内容就是 MySQL 备份失败的问题分析和处理是怎样的，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注丸趣 TV 行业资讯频道。