mysql 5.5 中對SLAVE relay-log相關日誌檔案同步的強化

在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的完整；
Enables automatic relay log recovery immediately following server startup,
which means that the replication slave discards all unprocessed relay logs
and retrieves them from the replication master.
This should be used following a crash on the replication slave to ensure that no possibly corrupted relay logs are processed.
The default value is 0 (disabled).
This global variable can be changed dynamically, or by starting the slave with the --relay-log-recovery option.