線上有一臺伺服器上，裡面有一個mysql資料庫服務，其實庫也很小，就幾個G，一直以來是保留了多天的備份集，但是因為業務的關係，這個庫其實只有一些 基本的資料查詢，但奇怪的是沒有從庫，一直以來是每天都會備份，保留了近一週的備份集，這種情況也倒相安無事。不過不巧的是這臺伺服器上還部署有 Oracle資料庫，空間要大很多，隨著業務的增長，這個資料量就上去了，結果空間的使用是越來越緊俏。保留一週的備份集，空間是越來越緊張。所以在一臺 Oracle的備庫機器上使用gtid建立了一個mysql從庫。這種情況基本可以滿足之前的需求，所以也就不需要每天做一個全備了。 這種情況持續了沒多少時間，有一天就收到了如下的報警。 ZABBIX-監控系統: ------------------------------------ 報警內容: Free disk space is less than 20% on volume / ------------------------------------ 報警級別: PROBLEM ------------------------------------ 監控專案: Free disk space on / (percentage)：1.94 % ------------------------------------ 報警時間:2016.02.23-11:01:07 好傢伙，這個分割槽竟然是直接使用了根目錄的空間，所以空間更是緊張了。 這個時候就需要調整資料的目錄地址了。想想也就是調整datadir的地址即可。 首先是調整資料的目錄地址，修改/etc/my.cnf,然後停庫，因為空間的問題，最後沒有剩餘空間了，結果從庫的應用直接hang住了，所以直接停庫的時候等了一些時間。 # /etc/init.d/mysql stop Shutting down MySQL (Percona Server)....................... SUCCESS!

啟庫的時候報了下面的錯誤。 # /etc/init.d/mysql start Starting MySQL (Percona Server)..... ERROR! The server quit without updating PID file (/U01/app/mysql_3306/mysql.pid). 經過一番排查，發現原來是檔案的目錄許可權的問題。 修復之後繼續啟動，還是同樣的報錯。 一時沒有思路，就測試了一下，把檔案目錄改回了原來的路徑，修改/etc/my.cnf裡面的路徑，再次啟庫，這個時候從庫開始接受應用日誌，過期的binlog都做了一些刪除。和追庫追平之後，再次停庫就很快了。 # /etc/init.d/mysql stop Shutting down MySQL (Percona Server)... SUCCESS! 但是遷移檔案之後，修改/etc/my.cnf之後再次啟庫就還是同樣的問題了。 [root@shadoop app]# /etc/init.d/mysql start Starting MySQL (Percona Server)..... ERROR! The server quit without updating PID file (/U01/app/mysql_3306/mysql.pid). 檢視error.log發現了下面的這一段內容，和之前一樣，不過有了新的發現。 160223 11:59:38 mysqld_safe mysqld from pid file /U01/app/mysql_3306/mysql.pid ended 160223 11:59:56 mysqld_safe Starting mysqld daemon with databases from /U01/app/mysql_3306 2016-02-23 11:59:56 21600 [Note] Plugin 'FEDERATED' is disabled. 2016-02-23 11:59:56 21600 [Note] InnoDB: The InnoDB memory heap is disabled 2016-02-23 11:59:56 21600 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2016-02-23 11:59:56 21600 [Note] InnoDB: Compressed tables use zlib 1.2.3 2016-02-23 11:59:56 21600 [Note] InnoDB: Using Linux native AIO 2016-02-23 11:59:56 21600 [Note] InnoDB: Using CPU crc32 instructions 2016-02-23 11:59:56 21600 [Note] InnoDB: Initializing buffer pool, size = 4.0G 2016-02-23 11:59:57 21600 [Note] InnoDB: Completed initialization of buffer pool 2016-02-23 11:59:57 21600 [Note] InnoDB: Highest supported file format is Barracuda. 2016-02-23 11:59:57 21600 [Note] InnoDB: 128 rollback segment(s) are active. 2016-02-23 11:59:57 21600 [Note] InnoDB: Waiting for purge to start 2016-02-23 11:59:57 21600 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.14-rel62.0 started; log sequence number 278581 8494 2016-02-23 11:59:57 7ffa261f0700 InnoDB: Loading buffer pool(s) from .//ib_buffer_pool ^G/usr/sbin/mysqld: File '/home/mysql_3306/mysql-bin.000006

' not found (Errcode: 2 - No such file or directory) 2016-02-23 11:59:57 21600 [ERROR] Failed to open log (file '/home/mysql_3306/mysql-bin.000006', errno 2) 2016-02-23 11:59:57 21600 [ERROR] Could not open log file 2016-02-23 11:59:57 21600 [ERROR] Can't init tc log 2016-02-23 11:59:57 21600 [ERROR] Aborting 就是mysql會嘗試去找一個binlog /home/mysql_3306/mysql-bin.000006 這部分的資訊在哪裡呢。 # less relay-index.index /home/mysql_3306/mysql-relay.000008 /home/mysql_3306/mysql-relay.000009 /U01/app/mysql_3306/mysql-relay.000010 /U01/app/mysql_3306/mysql-relay.000011 帶著新鮮勁，手工修改了一下這個檔案，看看能不能生效。 修改為： # vi relay-index.index /U01/app/mysql_3306/mysql-relay.000008 /U01/app/mysql_3306/mysql-relay.000009 /U01/app/mysql_3306/mysql-relay.000010 /U01/app/mysql_3306/mysql-relay.000011 然後嘗試change master讓它基於最新的時間點重新同步。 > change master to master_host='10.127.0.xx',master_port =3306,master_user='repl',master_password='slaveuser',master_auto_position=1; Query OK, 0 rows affected, 2 warnings (0.00 sec) 啟動slave的時候就報了下面的錯誤。 > start slave; ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository 重啟之後，繼續嘗試start slave,發現錯誤依舊。 這個時候的方法只有reset slave了。 > start slave; ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository > reset slave; Query OK, 0 rows affected (0.00 sec) > change master to master_host='10.127.0.xx',master_port =3306,master_user='repl',master_password='slaveuser',master_auto_position=1; Query OK, 0 rows affected, 2 warnings (0.04 sec) > start slave; Query OK, 0 rows affected (0.01 sec) 再次檢視slave已經和主庫的日誌追平了。 > show slave statusG *************************** Replicate_Ignore_Server_Ids: Master_Server_Id: 200 Master_UUID: 170281bc-1957-11e4-ad6e-842b2b4841e9 Master_Info_File: /U01/app/mysql_3306/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it Master_Retry_Count: 86400 reset slave會使得slave忘記主從複製關係的位置資訊。該語句會刪除master.info檔案和relay-log.info 檔案以及所有的relay log 檔案並重新啟用一個新的relaylog檔案。 使用reset slave之前必須使用stop slave 命令將複製程序停止，所有的relay log將被刪除不管他們是否被SQL thread程序完全應用。 不過如果延遲不大，這些都不是事。畢竟這個問題解決了總比隔三差五收到報警手工處理要好很多。