這篇文章給大家介紹如何通過MySQL relaylog + SQL_Thread 增量恢復binlog，內(nèi)容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
創(chuàng)新互聯(lián)公司服務項目包括黎川網(wǎng)站建設、黎川網(wǎng)站制作、黎川網(wǎng)頁制作以及黎川網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，黎川網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到黎川省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！
數(shù)據(jù)回檔常常是使用全量備份+binlog增量實現(xiàn)的。
而數(shù)據(jù)量很大的情況下，增量恢復binlog一直是一個苦惱的問題，因為恢復binlog速度十分慢，并且容易出錯。
恢復binlog文件一般有兩種方法：
〇 先解析成sql文件，再導入MySQL
mysqlbinlog mysql-bin.000001 --start-position=n > /data/add.sql
mysqlbinlog mysql-bin.000002 ... mysql-bin.n >> /data/add.sql
mysql -u -p -S < /data/add.sql
〇 直接管道到MySQL中
mysqlbinlog mysql-bin.000001 --start-position=n | mysql -u -p -S
mysqlbinlog mysql-bin.000002 ... mysql-bin.n | mysql -u -p -S
關于這種方式的更多info，可以參考：
https://dev.mysql.com/doc/refman/5.7/en/point-in-time-recovery.html
然而這兩種方式原理都是一樣的，通過mysqlbinlog解析成sql并導入到MySQL中。
〇 優(yōu)點：
操作方便，邏輯簡單。
無需關閉mysqld。
〇 缺點：
遇到ERROR難以定位位置，難以“斷點恢復”。
特殊字符或字符集的問題。
max_allowed_packet問題。
恢復速度慢。
因為relaylog和binlog本質(zhì)實際上是一樣的，所以是否可以利用MySQL自身的sql_thread來增量binlog呢？
〇 處理思路：
1）重新初始化一個實例，恢復全量備份文件。
2）找到第一個binlog文件的position，和剩下所有的binlog。
3）將binlog偽裝成relaylog，通過sql thread增量恢復。
這里只介紹核心部分，即偽裝成relaylog的過程。
① 將relay log info的repository改到file中，并生成這個文件。
SET GLOBAL relay_log_info_repository='FILE';
CHANGE MASTER TO master_host='1',master_password='1',master_user='1',master_log_file='1',master_log_pos=4;
通過change命令，是為了告訴MySQL自己為一個slave實例，因為無需用到IO_Thread，故host，password，user等可以隨意填寫。
并且通過該步驟，生成relay.info文件。
② 關閉實例，將需要增量的binlog文件偽裝成relaylog。
cp mysql-bin.000003 mysql-bin.000004 mysql-bin.000005 mysql-bin.000006 mysql-bin.000007 mysql-bin.000008 mysql-bin.000009 mysql-bin.000010 $relaylogdir
cd $relaylogdir
rename mysql-bin. mysql-relay. mysql-bin.0000*
chown mysql:mysql -R .
通過cp命令將binlog移動到$relaylogdir里，該變量取決于實例的選項參數(shù)，默認放在datadir下。
再將binlog批量改名成relaylog，并且給予對應的權限，否則會報錯OS error code 13: Permission denied。
③ 修改relay.info文件和relay-log.index文件
將relay.info的第二三行改成需要執(zhí)行的第一個binlog（現(xiàn)在是relaylog）的文件名和position：
/data/mysql57/relaylog/mysql-relay.000003
1276895
第二三行對應Relay_log_name和Relay_log_pos，等同于：
mysqlbinlog mysql-relay.000003 --start-position=1276895 | mysql -u -p -S
修改該文件是為了告訴SQL_Thread從哪一個文件和哪一個position開始執(zhí)行事務
再修改relay-log.index，清空原有信息，添加以下信息，為的是告訴SQL_Thread還有哪些relaylog是需要執(zhí)行的。
/data/mysql57/relaylog/mysql-relay.000003
/data/mysql57/relaylog/mysql-relay.000004
/data/mysql57/relaylog/mysql-relay.000005
/data/mysql57/relaylog/mysql-relay.000006
/data/mysql57/relaylog/mysql-relay.000007
/data/mysql57/relaylog/mysql-relay.000008
/data/mysql57/relaylog/mysql-relay.000009
/data/mysql57/relaylog/mysql-relay.000010
④ 啟動實例，開啟SQL_Thread：
START SLAVE sql_thread ;
只需要開啟SQL_Thread即可
⑤ 檢查復制狀態(tài)：
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 1
Master_User: 1
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: 1
Read_Master_Log_Pos: 4
Relay_Log_File: mysql-relay.000003 -- 已經(jīng)執(zhí)行到的日志名
Relay_Log_Pos: 11529982 -- 已經(jīng)執(zhí)行到日志的位置
Relay_Master_Log_File: 1
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 11529982
Relay_Log_Space: 5347038913
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 274354 -- 若變?yōu)?，則表示已經(jīng)增量完畢
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 0
Master_UUID:
Master_Info_File: /data/mysql57/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Reading event from the relay log
Master_Retry_Count: 86400
………………………………
該測試使用的版本為：MySQL 5.7.16
效果：恢復全備文件+binlog恢復到故障前的最后一個position。
其他場景也適用，比如在某一時刻執(zhí)行了錯誤的sql，如truncate等操作，同樣也可以通過該辦法。
只需要將START SLAVE sql_thread后添加一個 UNTILRELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos即可。
該選項用于控制SQL_Thread執(zhí)行到的最后的position，類似于mysqlbinlog mysql-bin.n --stop-position=$log_pos 。
除了更準確的能夠恢復錯誤之外，還有一個最大的好處是加快了binlog增量的速度。
補充一個額外的測試數(shù)據(jù)
對于同一組binlog文件增量：
通過mysqlbinlog解析+導入的時間為69min。
而通過SQL_Thread的執(zhí)行時間為41min。
并且在需要增量的binlog文件越大的情況下，效果越明顯。
〇 優(yōu)點：
可以斷點恢復，人為控制進度，比如stop slave或者遇到錯誤時，可以斷點恢復。
性能好，在大量binlog的情況下，可以加快恢復速度。
在某些版本可以利用多線程復制來加快增量速度，時恢復更快。
〇 缺點：
需要關閉mysqld。
手動執(zhí)行過程較mysqlbinlog方式更為復雜。
〇 總結：
mysqlbinlog --start-position 與 通過修改relay.info的第三行等效：
用途都是指定開始執(zhí)行的第一個position。
mysqlbinlog --stop-position 與 通過在啟動SQL_Thread時指定UNTIL RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos等效：
用途都是指定結束執(zhí)行的最后一個position。
關于如何通過MySQL relaylog + SQL_Thread 增量恢復binlog就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
重慶分公司
重慶分公司
