MySQL主从同步报错1507

事件发现及排查：

早上来公司第一件事，习惯性的打开邮箱，收收报警邮件，看看监控。看到一个sql实例（从库）报警磁盘空间不足。当时没有引发足够的注意，习惯性的登录服务器开始查看binlog过时时间，查看relay log清理信息。

mysql> select @@version;
+--------------+
| @@version    |
+--------------+
| 5.7.10-3-log |
+--------------+
1 row in set (0.00 sec)
mysql> show variables like 'relay_log_purge';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| relay_log_purge | ON    |
+-----------------+-------+
1 row in set (0.01 sec)

mysql> show variables like 'expire_logs_days';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days | 3     |
+------------------+-------+
1 row in set (0.00 sec)

看起来一切正常，我这是800多G的SSD。有点诡异，看下主库的磁盘空间使用状况

tom@sql09:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        58G   32G   23G  59% /
devtmpfs         32G     0   32G   0% /dev
tmpfs            32G   12K   32G   1% /dev/shm
tmpfs            32G  3.2G   29G  11% /run
tmpfs            32G     0   32G   0% /sys/fs/cgroup
/dev/sda1       283M  113M  152M  43% /boot
/dev/sda5       814G  587G  186G  76% /home
tmpfs           6.3G     0  6.3G   0% /run/user/99
tmpfs           6.3G     0  6.3G   0% /run/user/10194

在看一下从库的磁盘空间使用状况

tom@sql10:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        58G   14G   41G  26% /
devtmpfs         32G     0   32G   0% /dev
tmpfs            32G   12K   32G   1% /dev/shm
tmpfs            32G  3.2G   29G  11% /run
tmpfs            32G     0   32G   0% /sys/fs/cgroup
/dev/sda1       283M  113M  152M  43% /boot
/dev/sda5       814G  704G   69G  92% /home
tmpfs           6.3G     0  6.3G   0% /run/user/99
tmpfs           6.3G     0  6.3G   0% /run/user/10194

对比一下主从库MySQL Data目录下文件大小，这里我就不贴图了（你懂的），发现主从库log目录差别巨大，从库明显比主库多了100G左右，进入从库log目录下，发现有大量的reloy log信息

tom@sql10:~/mysql/log$ 
mysql-relay-bin.092121  mysql-relay-bin.092383  mysql-relay-bin.092645  mysql-relay-bin.092907  mysql-relay-bin.093169  mysql-relay-bin.093431  mysql-relay-bin.093693  mysql-relay-bin.093955
......
......
......

从库relay log purge已经打开，log日志怎么会有这么多relay log文件呢？第一反应就是从库的主从出问题了，登录从库查看主从状态

故障现场

Last_Errno: 1507
                   Last_Error: Error 'Error in list of partitions to DROP' on query. Default database: ''. Query: 'ALTER TABLE  DROP PARTITION part_20170209'

 

 

解决办法：

根据从库报错到相应位置查看要删除的分区，发现果真没有那个分区。问题到这里已经很明朗了，剩下的就是简单的一些修复操做

mysql> stop slave ;
Query OK, 0 rows affected (0.00 sec)

mysql> set global sql_slave_skip_counter=1;
Query OK, 0 rows affected (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

重复上面的操做，直到问题获得修复。若是一样的报错不少，也能够本身写一个脚本，不断监控mysql slave状态，若是匹配到一样的报错就跳过。下面来看一下修复后的状况

Seconds_Behind_Master: 330860
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error:

感受还好，只是这个延迟有点太大了，90多个小时。此刻我也只能在内心默念：SSD快跑

 

 

个人思考：

一、出现这样的问题，首先能够确定的是，有人为用大权限帐号在从库手动执行drop partition操做，致使主库执行的时候从库没有发现这个partition报错。要控制这样的问题，能够从权限着手，严格控制用户权限，非DBA人员直接不让他有操做权限（咱们的权限是很严格的）

二、监控报警不到位，从库主从停了几天了，一直没有收到报警，后期能够把监控系统完善一下

 

为了方便你们交流，本人开通了微信公众号，和QQ群291519319。喜欢技术的一块儿来交流吧