一波三折的问题分析和处理

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

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

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

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

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

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

错误的信息是比较明显了，是主库的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的关系更

（编辑：南通站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!