【FAQ系列】Relay log 致使複製啓動失敗

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

版本:MySQL5.6.27 

1、報錯現象mysql

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

這個時候查看error.log:sql

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的基礎知識:socket

2、MySQL Relay log介紹工具

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

一、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文件了。rest

三、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的值

下面解決問題:

dba:(none)> reset slave;
Query OK, 0 rows affected (0.00 sec)
dba:(none)> change master to ......
dba:(none)> start slave;
Query OK, 0 rows affected (0.00 sec)

到這裏問題解決了。

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

 

 

【參考資料】:https://dev.mysql.com/doc/refman/5.6/en/slave-logs.html

                         https://dev.mysql.com/doc/refman/5.6/en/reset-slave.html

相關文章
相關標籤/搜索