title: sync_binlog parameter
body: <p>I was going through the documentation for sync_binlog parameter and found a discrepancy in sync_binlog parameter documentation.</p>
  <p>The documentation here <a href="http://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#sysvar_sync_binlog" rel="nofollow noreferrer">http://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#sysvar_sync_binlog</a> says:</p>
  <p><em>A value of 1 is the safest choice because in the event of a crash you lose at most one commit group from the binary log.</em></p>
  <p>Which essentially means that the data will be updated but might not be there in the binlogs.</p>
  <p>However, in the binary log documentation here <a href="http://dev.mysql.com/doc/refman/5.6/en/binary-log.html" rel="nofollow noreferrer">http://dev.mysql.com/doc/refman/5.6/en/binary-log.html</a> says:</p>
  <p><em>For example, if you are using InnoDB tables and the MySQL server processes a <code>COMMIT</code> statement, it writes many prepared transactions to the binary log in sequence, synchronizes the binary log, and then commits this transaction into InnoDB. If the server crashes between those two operations, the transaction is rolled back by InnoDB at restart but still exists in the binary log.</em></p>
  <p>Which essentially means that the transaction is first written in binlog and then committed to the InnoDB, so there is a chance that in case of crash the row is there in the binlog but doesn't exist in the Database.</p>
  <p>I have asked this question in MySQL forum and waiting for the response, but would really appreciate if someone who has used this parameter can give the details on which of the following two behaviour is correct?</p>