mysql 5.5 中如何對SLAVE relay-log相關日志文件同步的強化

這期內容當中小編將會給大家帶來有關mysql 5.5 中如何對SLAVE relay-log相關日志文件同步的強化，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

在5.1版本中，slave 從MASTER拿到日志后，寫到relay-log,并進行SQL應用；
在這里注意，寫到RELAY-LOG，指的是先寫到 “OS cache”的relay-log，而不是馬上刷新到磁盤上；
什么時候刷新還依賴于操作系統的CACHE刷新時間；

[@more@]

如果在這期間，一個日志剛同步到"relay-log @os cache ",而沒有被刷新到"relay-log @disk", OS CRASH, 那么這個日志將丟失；
（這個問題不用擔心：MYSQL會在重啟后重新從MASTER獲取日志）

同樣存在一致問題的相關SLAVE文件還有：relay-log.info ; master.info;
如果這兩個文件發生不一致，問題就不那么好辦了；很可能發生重復執行SQL或重新讀取日志；

在V5.5中，MYSQL對這一塊進行了強化，增加三個參數：
sync_relay_log_info # default 0
sync_master_info    # default 0
sync_relay_log      # default 0

讓他們來控制，每隔多少個SLAVE日志“語句/事務”，觸發同步一次相關文件；
-----------------------------------------------------------

# sync_relay_log_info

If the value of this variable is greater than 0,
a replication slave synchronizes its relay-log.info file to disk (using fdatasync()) after every sync_relay_log_info transactions.
A value of 1 is the generally the best choice.
The default value of sync_relay_log_info is 0,
 which does not force any synchronization to disk by the MySQL server—in this case,
 the server relies on the operating system to flush the relay-log.info file's contents from time to time as for any other file.

# sync_master_info

If the value of this variable is greater than 0,
a replication slave synchronizes its master.info file to disk (using fdatasync()) after every sync_master_info events.

The default value of sync_relay_log_info is 0 (recommended in most situations),
which does not force any synchronization to disk by the MySQL server;
in this case, the server relies on the operating system to flush the master.info file's contents from time to time as for any other file.

# sync_relay_log

If the value of this variable is greater than 0,
the MySQL server synchronizes its relay log to disk (using fdatasync()) after every sync_relay_log writes to the relay log.
There is one write to the relay log per statement if autocommit is enabled, and one write per transaction otherwise.
The default value of sync_relay_log is 0, which does no synchronizing to disk—in this case,
the server relies on the operating system to flush the relay log's contents from time to time as for any other file.
A value of 1 is the safest choice because in the event of a crash you lose at most one statement or transaction from the relay log.
However, it is also the slowest choice (unless the disk has a battery-backed cache, which makes synchronization very fast).

他們的工作模式和效果有點像：sync_binlog 參數，在設置的時候我們要注意IO性能評估，特別是對relay-log的sync；
一般的SLAVE，即打開BINLOG寫，現在又要頻繁刷新relay-log寫，對IO的壓力有所增加；

比如：relay-log.info　的刷新：
假如我們最安全地設置sync_relay_log_info=1 ， 那么每執行完一個SQL/事務，SLAVE進程更新relay-log.info后，就需要刷到DISK；
假設我們機器能執行QPS=1000，這也就要求relay-log.info刷新1000次；（當然DISK如果有RAID CACHE，并且write-back生效；情況會好很多）
算起來還是很嚇人的；

但考慮到SLAVE一般不承載SELECT帶來的壓力 ；所以壓力一般不會超過MASTER；
只要MASTER與SLAVE硬件配置相當；應該是不用擔心這個問題；

另外,v5.5中還有一個參數：relay_log_recovery ，
當被設置成ENABLED，在CRASH后自動放棄所有未執行的relay-log,并且重新從MASTER獲取日志；這樣保證relay-log的完整；

在服務器啟動后立即啟用自動中繼日志恢復，

這意味著復制從機將丟棄所有未處理的中繼日志

并從復制主機檢索它們。

這應該在復制從機崩潰后使用，以確保不會處理可能損壞的中繼日志。

默認值為0（已禁用）。

可以動態更改此全局變量，或者通過使用--relay log recovery選項啟動從機來更改。

上述就是小編為大家分享的mysql 5.5 中如何對SLAVE relay-log相關日志文件同步的強化了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。