今天和同事一起处理了一个奇怪的MySQL空间异常问题，从这个问题的处理上我们可以找到一些处理问题的方法。问题产生的背景是一个实例的备份总是失败。经过多方考察，搁置以确保Slave可用。正好这几天整理整理完毕。备份失败的错误信息为：innobackupex:Errorwritingfile'/tmp/xbtempevLQbf'(Errcode:28-Nospaceleftondevice)xtrabackup:Error:writetologfilefailedxtrabackup: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./home411M./lib26M./lib6416K./lost+found4.0K./media4.0K./misc4.0K./mnt0./net184M./optdu:cannotaccess`./proc/40102/task/40102/fd/4':Nosuchfileordirectorydu:cannotaccess`./proc/40102/task/40102/fdinfo/4':Nosuchfileordirectorydu:cannotaccess`./proc/40102/fd/4':Nosuchfileordirectorydu:cannotaccess`./proc/40102/fdinfo/4':Nosuchfileordirectory0./proc2.3G./root56K./tmp...所以从目前的情况来看，应该是/proc相关目录的空间出现了异常。这个时间点，好像能用的方法不多。我检查了脚本并检查了参数文件。整体来说，和其他环境相比没有明显的问题，但是有一个细节引起了我的注意。在使用top的时候，看到这个实例的内存用了6G（服务器内存是8G），但是bufferpool的配置是3G左右。这是从库环境，没有应用程序连接，所以不太可能有过多的连接资源消耗。所以综合来看，应该是连接到内存异常相关的服务器上。这时候试了一下onlineresize，发现已经没有收缩的空间了。因为是从库服务，所以我开始重启从库服务。但是没想到，重启数据库的时候就卡住了。大约2分钟后，我只在输出中看到了一些小数点。输出了两行左右，还是没有任何反应。后台日志没有任何输出，于是开始尝试B计划，准备Kill进程重启服务。这次kill操作生效了，过了一会服务就启动了。但是从库中复制却报异常。Last_IO_Error：从二进制日志中读取数据时从主服务器收到致命错误1236：“从服务器正在使用CHANGEMASTERTOMASTER_AUTO_POSITION=1进行连接，但主服务器已清除包含从服务器所需的GTID的二进制日志。”。..Master_Server_Id：190Master_UUID：570dcd0e-f6d0-11e8-adc3-005056b7e95f。..Slave_SQL_Running_State:Slavehasreadallrelaylog;waitingformoreupdatesMaster_Retry_Count:86400Master_Bind:Last_IO_Error_Timestamp:20021114:20:57Retrieved_Gtid_Set:570dcd0e-f6d0-11e8-adc3-005056b7e95f:821211986-2157277214Executed_Gtid_Set:570dcd0e-f6d0-11e8-adc3-005056b7e95f:1-820070317:821211986-2157277214这个错误的信息比较明显。主库binlog被purge，导致从库copy应用失败。为什么会出现这么奇怪的问题，因为主库的binlog默认还是保留一定天数的，1小时前的binlog不会被删除。关于GTID的一些变量值如下:Retrieved_Gtid_Set:570dcd0e-f6d0-11e8-adc3-005056b7e95f:821211986-2157277214Executed_Gtid_Set:570dcd0e-f6d0-11e8-adc3-005056b7e95f:1-820070317:821211986-2157277214gtid_purged：570dcd0e-f6d0-11e8-adc3-005056b7e95f:1-820070317:821211986-2131381624Master端的GTID_Purged为：gtid_purged:570dcd0e-f6d0-11e8-adc3-005056b7e95f:1-2089314252表示GTID与master端没有完全连接。之前在这个Slave上做过一些操作，导致Master和Slave的GTID有些偏差。而这个缺失的变化部分570dcd0e-f6d0-11e8-adc3-005056b7e95f:821211986保守估计是1个月前的，肯定没有保留binlog。让我们在这里暂时解决这个复制问题。StoppingtheSlave没想到又出问题了。一次看似简单的stopSlave操作持续了1分多钟。>>stopslave;QueryOK,0rowsaffected(1min1.99sec)尝试减少Bufferpool配置，重启，stopslave，这个操作还是很慢，所以可以排除这个方向延迟的问题并且它与BufferPoolLarge无关，但与GTID相关。Slave端修复步骤如下：resetmaster;stopslave;resetslaveall;SET@@GLOBAL.GTID_PURGED='570dcd0e-f6d0-11e8-adc3-005056b7e95f:1-2157277214';CHANGEMASTERTOMASTER_USER='dba_repl',MASTER_MASTWORD',xxxxxxxx',MASTER_PORT=4308,MASTER_AUTO_POSITION=1;GTID_PURGED的配置是关键。修复后，解决了Slave端的延迟问题，再次尝试备份时，根目录没有空间消耗。总结：这个过程的主要目的是快速解决问题。一些步骤的日志不够丰富和详细。从问题的分析来看，还是缺少一些更有说服力的东西。问题的根源还是不合理的问题（比如bug或者配置异常等）导致不合理的现象。这方面仍然可以借鉴的是分析的整体思路，而不是问题本身。
