在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.