mysql 主從備庫重起初始化relay log 失敗的處理

今天在使用冷備份文件重作從庫時遇到一個報錯，值得研究一下。

版本：MySQL5.6.27　

1、報錯現象

dba:(none)> start slave;ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository

這個時候查看error.log:

1 2 3 4 5 6 7 8

2017-07-17 16:19:02 9022 [ERROR] Failed to open the relay log './tjtx-96-67-relay-bin.017814' (relay_log_pos 172582079). 2017-07-17 16:19:02 9022 [ERROR] Could not find target log file mentioned in relay log info in the index file './tjtx135-1-95-relay-bin.index' during relay log initialization. 2017-07-17 16:19:02 9022 [ERROR] Failed to initialize the master info structure 2017-07-17 16:19:02 9022 [Note] Check error log for additional messages. You will not be able to start replication until the issue is resolved and the server restarted. 2017-07-17 16:19:02 9022 [Note] Event Scheduler: Loaded 0 events 2017-07-17 16:19:02 9022 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.6.27-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL) 2017-07-17 16:19:06 9022 [ERROR] Slave SQL: Slave failed to initialize relay log info structure from the repository, Error_code: 1872

從報錯上看，意思是啓動slave時，使用repository中信息初始化relay log結構失敗了。爲何失敗了？原來是從tjtx135-1-95-relay-bin.index文件中找不到tjtx-96-67-relay-bin.017814文件。到這裏，答案就很清楚了，因爲我使用的是冷備份文件恢復的實例，在mysql庫中的slave_relay_log_info表中依然保留以前relay_log的信息，因此致使啓動slave報錯。

那如何解決呢？先來簡單的瞭解MySQL Relay log的基礎知識：

2、MySQL Relay log介紹

在MySQL複製結構下，Slave服務器會產生三種日誌文件，用來保存主庫的二進制日誌事件以及relay log已執行到的位置和狀態。

一、relay log 文件：由IO thread線程從主庫讀取的二進制日誌事件組成，該日誌被Slave上的SQL thread線程執行，從而實現數據的複製。

二、master info log：該文件保存slave鏈接master的狀態以及配置信息，如用戶名，密碼，日誌執行的位置等。在5.6版本以前，都是使用master.info文件，從5.6開始，經過在my.cnf 中配置 --master-info-repository=TABLE。這些信息會被寫入mysql.slave_master_info 表中，代替原來的master.info文件了。

三、relay log info log：該文件保存slave上relay log的執行位置。在5.6版本以前，都是使用relay-log.info文件，從5.6開始，經過在my.cnf中配置 --relay-log-info-repository=TABLE，使用mysql.slave_relay_log_info表代替原來的文件。每次當slave上執行start slave時，就會讀取該表中的位置信息。

新版本使用表來代替原來的文件，主要爲了crash-safe replication，從而大大提升從庫的可靠性。爲了保證意外狀況下從庫的可靠性，mysql.slave_master_info和mysql.slave_relay_log_info表必須爲事務性的表，從5.6.6起，這些表默認使用InnoDB存儲引擎。在5.6.5及以前的版本默認使用MyISAM引擎，可用下面語句進行轉換：

ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;

【注意】不要試圖手工的更新、插入、刪除以上兩個表的內容，以避免出現意料不到的問題。

3、問題解決

經過上面的報錯以及relay log介紹，很容易知道因爲mysql.slave_relay_log_info表中保留了之前的複製信息，致使新從庫啓動時沒法找到對應文件，那麼咱們清理掉該表中的記錄不就能夠了。再次提醒，不要手動刪該表數據，MySQL已經提供工具給咱們了：reset slave：

reset slave乾的那些事：

1、刪除slave_master_info ，slave_relay_log_info兩個表中數據；2、刪除全部relay log文件，並從新建立新的relay log文件；3、不會改變gtid_executed 或者 gtid_purged的值

下面解決問題：

1 2	dba:(none)> reset slave; Query OK, 0 rows affected (0.00 sec)

1	dba:(none)> change master to ......

1 2	dba:(none)> start slave; Query OK, 0 rows affected (0.00 sec)

到這裏問題解決了。

【經驗】：之後用冷備份恢復實例後，在啓動slave前，先進行reset slave清空下之前的舊信息。

——————————————————————————————————————————

重慶思莊IT技術學習中心

重慶思莊OCP認證培訓班火熱報名中，詳情訪問思莊網站諮詢在線客服！1月OCP（週末+脫產）班正在面授，歡迎聯繫試聽！