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。喜歡技術的一塊兒來交流吧