Why Does a Slave’s Binlog Appear Larger Than the Master’s? Understanding MySQL sync_binlog

In a MySQL production environment a colleague observed that after the master server crashed the slave’s binary log contained more entries than the master, which seemed contradictory because the data were supposedly identical.

The cause was that the master’s sync_binlog variable was set to 0. With this setting MySQL writes transaction commits to the binlog cache but does not force the cache to be flushed to disk. The cache is still replicated to the slave, so the slave receives the events. If the master crashes before the cache is flushed, the cached events are lost, making the master’s on‑disk binlog shorter than the slave’s.

After re‑configuring replication and changing sync_binlog to 1, the problem disappeared. Setting sync_binlog=1 tells MySQL to issue an fsync (or similar) after each transaction commit, forcing the binlog cache to be written to disk.

MySQL’s default is sync_binlog=0, which maximizes performance because no explicit disk‑sync is performed, but it also carries the highest risk: any crash will discard all binlog information that resides only in the cache. Using sync_binlog=n (where n > 0) makes MySQL perform a disk sync after every n transactions, balancing durability and throughput.