MySQL遷移檔案的小問題

線上有一臺伺服器上，裡面有一個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 () 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 status\G
***************************
  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程式完全應用。
不過如果延遲不大，這些都不是事。畢竟這個問題解決了總比隔三差五收到報警手工處理要好很多。