Bug #71323 Implicit commits don't write binary log before writing Innodb log.
Submitted: 9 Jan 2014 10:21 Modified: 27 Jan 2014 14:53
Reporter: Kenta Tada Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: Logging Severity:S3 (Non-critical)
Version:5.6.x OS:Any
Assigned to: CPU Architecture:Any

[9 Jan 2014 10:21] Kenta Tada
Description:
The statements that cause an implicit commit are not written to binary log before writing Innodb log from MySQL 5.6. Is this behavior as designed?

From MySQL 5.6, binary log is written before writing Innodb log in BINLOG:ordered_commit.
But when executing the statements that cause an implicit like DDL, Innodb log is written before writing binary log.
When I tested this behavior using GDB(kill mysqld process when mysqld enters BINLOG:ordered_commit after executes "create table"), Innodb log was only written. If mysqld starts crash recovery in this situation, Innodb log and binary log will not be synchronized.

How to repeat:
N/A

Suggested fix:
N/A
[26 Jan 2014 14:08] Sveta Smirnova
Thank you for the report.

How do you test if InnoDB log written after ordered_commit. I set breakpoint in log_group_write_buf and it is called before ordered_commit in any case.
[27 Jan 2014 13:40] Kenta Tada
I just set breakpoint in ordered_commit().
My test is as described below in MySQL5.6.14:
1. set breakpoint in ordered_commit()
2. mysql prompt : create database testdb1;
(stopping when mysqld thread enters ordered_commit())
3. force mysqld shutdown.
4. start mysqld.
5. check difference between "show databases" and binary log.

testdb1 will be created after crash recovery but binary log will not include "create database testdb1". This recovery only happens after mysql_create_db() creates directory of database.
[27 Jan 2014 14:53] Sveta Smirnova
Thank you for the feedback.

Your case does not show difference in handling explicit and implicit commit. My test shows they handled in the same way.

Also we don't promise to write anything to binary log prior than to InnoDB log. Even more, such behavior will be dangerous, because in case of crash binary log will contain data which is not in the database. This can make replication de-synchronized. Closing as not a bug.