MySQL Bugs: #81800: sync_binlog and innodb_support

Bug #81800	sync_binlog and innodb_support_xa documentation improvement
Submitted:	10 Jun 2016 8:29	Modified:	26 Jan 2017 20:49
Reporter:	Frederic Descamps	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Documentation	Severity:	S3 (Non-critical)
Version:	5.7	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Hi,

In the documentation (https://dev.mysql.com/doc/refman/5.7/en/binary-log.html) we can read: [...]The InnoDB logs are synchronized by default, and sync_binlog=1 can be used to synchronize the binary log. The effect of this option is that at restart after a crash, after doing a rollback of transactions, the MySQL server removes rolled back InnoDB transactions from the binary log. This ensures that the binary log reflects the exact data of InnoDB tables, and therefore the slave remains in synchrony with the master because it does not receive a statement which has been rolled back.

In fact, according to sql/binlog.cc, the order of operations is different.
The binary log is the source of truth when innodb_support_xa is
enabled (the default and the recommended when binary log is ON). On
recovery, the server will then:

1. scan the latest binary log file;
2. collect xids for transactions written to the binary log file;
3. calculate the last position of the file that is still valid
if the file was not closed properly;
4. tell InnoDB to complete those transactions that were in
prepared state and that had been written already to the
binary log successfully (i.e., have their xid in the list
collected in #2)
5. truncate the binary log to the position found in #3, so
that the binary log file does not have corrupted data in
it.

The current documentation seems to indicate according to me (and Luìs) the opposite.

How to repeat:
This is a documentation bug and doesn't require any reproduction.

Thank you for the bug report.

Posted by developer:
 

For version 5.5, 5.6, 5.7, and 8.0 versions of the reference manual, this text:

"The effect of this option is that at
restart after a crash, after doing a rollback of transactions, the MySQL
server removes rolled back InnoDB transactions from the binary log."

was changed to:

"The effect of this option is that at restart after a crash, after doing a
rollback of transactions, the MySQL server scans the latest binary log
file to collect transaction xid values and calculate the last valid
position in the binary log file. The MySQL server then tells InnoDB to
complete any prepared transactions that were successfully written to the
to the binary log, and truncates the binary log to the last valid
position."

Thank you for the bug report.