線上有一臺服務(wù)器上，里面有一個MySQL數(shù)據(jù)庫服務(wù)，其實庫也很小，就幾個G，一直以來是保留了多天的備份集，但是因為業(yè)務(wù)的關(guān)系，這個庫其實只有一些基本的數(shù)據(jù)查詢，但奇怪的是沒有從庫，一直以來是每天都會備份，保留了近一周的備份集，這種情況也倒相安無事。不過不巧的是這臺服務(wù)器上還部署有Oracle數(shù)據(jù)庫，空間要大很多，隨著業(yè)務(wù)的增長，這個數(shù)據(jù)量就上去了，結(jié)果空間的使用是越來越緊俏。保留一周的備份集，空間是越來越緊張。所以在一臺Oracle的備庫機器上使用gtid創(chuàng)建了一個mysql從庫。這種情況基本可以滿足之前的需求，所以也就不需要每天做一個全備了。
    這種情況持續(xù)了沒多少時間，有一天就收到了如下的報警。

ZABBIX-監(jiān)控系統(tǒng):
------------------------------------
報警內(nèi)容: Free disk space is less than 20% on volume /
------------------------------------
報警級別: PROBLEM
------------------------------------
監(jiān)控項目: Free disk space on / (percentage)：1.94 %
------------------------------------
報警時間:2016.02.23-11:01:07
好家伙，這個分區(qū)竟然是直接使用了根目錄的空間，所以空間更是緊張了。
這個時候就需要調(diào)整數(shù)據(jù)的目錄地址了。想想也就是調(diào)整datadir的地址即可。
首先是調(diào)整數(shù)據(jù)的目錄地址，修改/etc/my.cnf,然后停庫，因為空間的問題，最后沒有剩余空間了，結(jié)果從庫的應(yīng)用直接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).
經(jīng)過一番排查，發(fā)現(xiàn)原來是文件的目錄權(quán)限的問題。
修復(fù)之后繼續(xù)啟動，還是同樣的報錯。
一時沒有思路，就測試了一下，把文件目錄改回了原來的路徑，修改/etc/my.cnf里面的路徑，再次啟庫，這個時候從庫開始接受應(yīng)用日志，過期的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發(fā)現(xiàn)了下面的這一段內(nèi)容，和之前一樣，不過有了新的發(fā)現(xiàn)。
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
重啟之后，繼續(xù)嘗試start slave,發(fā)現(xiàn)錯誤依舊。
這個時候的方法只有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已經(jīng)和主庫的日志追平了。
> 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忘記主從復(fù)制關(guān)系的位置信息。該語句會刪除master.info文件和relay-log.info 文件以及所有的relay log 文件并重新啟用一個新的relaylog文件。
使用reset slave之前必須使用stop slave 命令將復(fù)制進程停止，所有的relay log將被刪除不管他們是否被SQL thread進程完全應(yīng)用。
不過如果延遲不大，這些都不是事。畢竟這個問題解決了總比隔三差五收到報警手工處理要好很多。

泉州ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)建站的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：13518219792（備注：SSL證書合作）期待與您的合作！

分享文章：MySQL遷移文件的小問題
瀏覽路徑：http://weahome.cn/article/pdcisj.html