If we set sync_binlog to 0, which can delay the OS syncing the binary log to disk, does that introduce any lag into the time it takes for slaves to replicate those binary logs? In other words, are binary logs relayed to slaves potentially before they're flushed to disk?
2 Answers
No, it should not.
MySQL is still writing to the binlog as it was before, it's simply not calling sync itself. It's letting the filesystem flush it to disk. MySQL isn't reading directly from the disk, it's reading from the virtual filesystem layer which already has the data before a sync would be called (if called).
The only major drawback I can think of setting that to 0 is in the event of a crash or interrupted access to the underlying storage you may lose the data that was not yet flushed to disk. In exchange, you will have less syncs which may improve performance to the underlying storage.
Setting it to 0 just lets the OS deal with syncs as it normally would with any other application. Setting it to 1 will offer you the absolute most durability, but performance will likely suffer somewhat.
I run my production servers with sync_binlog=0 and have never noticed any sort of delay. Raising it above 0 might cause a measurable delay if your underlying storage is really slow.
The manpage for fdatasync(2) may help you understand better.
I know, it is bit late to answer, but for a quick reference.
One of the links I came across from abdel-mawla (good article !) which shows 'Throughput' comparison when sync_log is marked as '0' and '1' :
http://www.fromdual.com/galera-cluster-vs-pxc-vs-mariadb-galera-cluster-benchmarking
Also, what could be seen from MySQL documentation, MySQL 5.7.7 comes with default value as 1, which can impact performance.
