圖文結合帶你搞懂MySQL日志之relay log（中繼日志）-有解無憂

GreatSQL社區原創內容未經授權不得隨意使用，轉載請聯系小編并注明來源，
GreatSQL是MySQL的國產分支版本，使用上與MySQL一致，
作者： KAiTO
文章來源：GreatSQL社區原創

什么是中繼日志（relay log）

中繼日志（relay log）只在主從服務器架構的從服務器上存在，從服務器（slave）為了與主服務器(Master)保持一致，要從主服務器讀取二進制日志的內容，并且把讀取到的資訊寫入本地的日志檔案中，這個從服務器本地的日志檔案就叫中繼日志，然后，從服務器讀取中繼日志，并根據中繼日志的內容對從服務器的資料進行更新，完成主從服務器的資料同步，

搭建好主從服務器之后，中繼日志默認會保存在從服務器的資料目錄下，

檔案名的格式是：從服務器名 - relay-bin.序號，中繼日志還有一個索引檔案：從服務器名 - relay-bin.index，用來定位當前正在使用的中繼日志，

file

（主從復制原理圖）

從服務器I/O執行緒將主服務器的二進制日志(binlog)讀取過來記錄到從服務器本地檔案，然后從服務器SQL執行緒會讀取中繼日志的內容并應用到從服務器，從而使從服務器和主服務器的資料保持一致，

中繼日志的作用

中繼日志用于主從服務器架構中，從服務器用來存放主服務器二進制日志內容的一個中間檔案，從服務器通過讀取中繼日志的內容，來同步主服務器上的操作，

中繼日志是連接mastert(主服務器)和slave(從服務器)的資訊，它是復制的核心，I/O執行緒將來自master的binlog存盤到中繼日志中，中繼日志充當緩沖，這樣master不必等待slave執行完成就可以發送下一個binlog，

查看中繼日志

中繼日志檔案的格式與二進制日志檔案相同，并且可以使用 mysqlbinlog 進行讀取

SET TIMESTAMP= 1615352328 /*!*/;
BEGIN
/*!*/;
# at 900
#211413 11:33:46 server id 1 end_log_pos 832 CRC32 0xcc16d651 Table_map:
`kaito`.`test` mapped to number 91
# at 950
#211413 11:33:46 server id 1 end_log_pos 872 CRC32 0x07e4047c Delete_rows: table id
91 flags: STMT_END_F -- server id 1 是主服務器，意思是主服務器刪了一行資料
BINLOG '
CD95YBMBAAAAMgAAAEADAAAAAFsAAAAAAAEABGRlbW8ABHRlc3QAAQMAAQEBAFHWFsw=
CD95YCABAAAAKAAAAGgDAAAAAFsAAAAAAAEAAgAB/wABAAAAfATkBw==
'/*!*/;
# at 1000

這一段的意思是，主服務器（“server id 1”）對表 kaito.test 進行了 2 步操作：

定位到表 kaito.test 編號是 91 的記錄，日志位置是 832
洗掉編號是 91 的記錄，日志位置是 872

相關引數決議

通過陳述句：show variables like '%relay%' 查看先骨干的relay的所有相關引數如下：

mysql> show variables like '%relay%';
+---------------------------+---------------------------------------+
| Variable_name             | Value                                 |
+---------------------------+---------------------------------------+
| max_relay_log_size        | 0                                     |
| relay_log                 | kaito-relay-bin                       |
| relay_log_basename        | /var/lib/mysql/kaito-relay-bin        |
| relay_log_index           | /var/lib/mysql/kaito-relay-bin.index  |
| relay_log_info_file       | relay-log.info                        |
| relay_log_info_repository | TABLE                                 |
| relay_log_purge           | ON                                    |
| relay_log_recovery        | OFF                                   |
| relay_log_space_limit     | 0                                     |
| sync_relay_log            | 10000                                 |
| sync_relay_log_info       | 10000                                 |
+---------------------------+---------------------------------------+
11 rows in set (0.00 sec)

max_relay_log_size：標記relay log 允許的最大值，如果該值為0，則默認值為max_binlog_size(1G)；如果不為0，則max_relay_log_size則為最大的relay_log檔案大小；
relay_log：定義relay_log的位置和名稱，如果值為空，則默認位置在資料檔案的目錄（datadir），檔案名默認為host_name-relay-bin.nnnnnn
relay_log_index：同relay_log，定義relay_log的位置和名稱；一般和relay-log在同一目錄
relay_log_info_file：設定relay-log.info的位置和名稱（relay-log.info記錄MASTER的binary_log的恢復位置和relay_log的位置）
relay_log_purge：是否自動清空不再需要中繼日志時，默認值為1(啟用)，
relay_log_recovery：當slave從庫宕機后，假如relay-log損壞了，導致一部分中繼日志沒有處理，則自動放棄所有未執行的relay-log，并且重新從master上獲取日志，這樣就保證了relay-log的完整性，默認情況下該功能是關閉的，將relay_log_recovery的值設定為 1時，可在slave從庫上開啟該功能，建議開啟，
relay_log_space_limit：防止中繼日志寫滿磁盤，這里設定中繼日志最大限額，
- 注意！但此設定存在主庫崩潰，從庫中繼日志不全的情況，不到萬不得已，不推薦使用！
sync_relay_log：這個引數和sync_binlog是一樣的，當設定為1時，slave的I/O執行緒每次接收到master發送過來的binlog日志都要寫入系統緩沖區，然后刷入relay log中繼日志里，這樣是最安全的，因為在崩潰的時候，你最多會丟失一個事務，但會造成磁盤的大量I/O
當設定為0時，并不是馬上就刷入中繼日志里，而是由作業系統決定何時來寫入，雖然安全性降低了，但減少了大量的磁盤I/O操作，這個值默認是0，可動態修改，建議采用默認值，
sync_relay_log_info：這個引數和sync_relay_log引數一樣，當設定為1時，slave的I/O執行緒每次接收到master發送過來的binlog日志都要寫入系統緩沖區，然后刷入relay-log.info里，這樣是最安全的，因為在崩潰的時候，你最多會丟失一個事務，但會造成磁盤的大量I/O，當設定為0時，并不是馬上就刷入relay-log.info里，而是由作業系統決定何時來寫入，雖然安全性降低了，但減少了大量的磁盤I/O操作，這個值默認是0，可動態修改，建議采用默認值，

以上只是簡單的介紹了每個引數的作用，這些引數具體的設定還是需要根據每個用戶的實際系統情況進行設定的；

參考文章

《MySQL是怎樣運行的--從根兒上理解MySQL》—小孩子4919（https://juejin.cn/book/6844733769996304392）

Enjoy GreatSQL ??

關于 GreatSQL

GreatSQL是由萬里資料庫維護的MySQL分支，專注于提升MGR可靠性及性能，支持InnoDB并行查詢特性，是適用于金融級應用的MySQL分支版本，

相關鏈接： GreatSQL社區 Gitee GitHub Bilibili

GreatSQL社區：

社區博客有獎征稿詳情：https://greatsql.cn/thread-100-1-1.html

技術交流群：

微信：掃碼添加GreatSQL社區助手微信好友，發送驗證資訊加群，

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/542029.html

標籤：其他

上一篇：圖文結合帶你搞懂MySQL日志之relay log（中繼日志）

下一篇：ClickHouse(11)ClickHouse合并樹MergeTree家族表引擎之SummingMergeTree詳細決議