Bug #71864 Binlog info seems outdated
Submitted: 27 Feb 2014 16:18 Modified: 7 May 2014 16:07
Reporter: Daniël van Eeden (OCA) Email Updates:
Status: Closed Impact on me:
Category:MySQL Enterprise Backup Documentation Severity:S3 (Non-critical)
Version:3.9.0 OS:Any
Assigned to: Daniel So CPU Architecture:Any

[27 Feb 2014 16:18] Daniël van Eeden
Page: http://dev.mysql.com/doc/mysql-enterprise-backup/3.9/en/bugs.backup.html

If you take a backup when there are temporary tables in the database, and you use those temporary tables to update or insert into normal tables, then applying the MySQL binlog to a backup can fail. That is, you might not be able to roll forward the backup to a particular point in time using the MySQL binlog. Temporary tables are not copied to the backup because the physical filenames #sql*.frm do not correspond to the logical table names that MySQL writes to the binlog. This problem might be removed in the future, if MySQL implements “row-level binlogging”. 

row-level binlogging... that's binlog_format=ROW, isn't it?

How to repeat:
See description
[27 Feb 2014 16:25] Daniël van Eeden
On the same page:
"When restoring an individual InnoDB table, as described in Section 5.4, “Backing Up and Restoring a Single .ibd File”, the table must not have been dropped or truncated in the MySQL server after the backup. Dropping or truncating an InnoDB table changes its internal table ID, and when the table is re-created the ID will not match the table ID from the backup data"

http://dev.mysql.com/doc/mysql-enterprise-backup/3.9/en/partial.restoring.single.html explains this in not applicable for 5.6...
[5 Mar 2014 11:19] MySQL Verification Team
Hello Daniel,

Thank you for the bug report.

[15 Apr 2014 20:33] Daniel So
The second mistake mentioned ("When restoring an individual InnoDB table, ...") has been corrected in the manual.

We are still working on the first limitation mentioned in the ticket.
[30 Apr 2014 15:42] Daniel So
Qualified the limitation (the first one, which triggered the ticket) in the manual: it only applies when the option --binlog-format=STATEMENT is used on the MySQL server.
[1 May 2014 5:52] Daniël van Eeden
The text is now up to date again. However I think it should mention binlog_format=MIXED to document all 3 possible settings. In this situation MIXED has the same issues as STATEMENT.
[7 May 2014 16:07] Daniel So
Thanks for you comment, Daniel. A reference to the "MIXED" setting for binlog-format has been added to the description of the limitation. The update will be visible soon at http://dev.mysql.com/doc/mysql-enterprise-backup/3.10/en/bugs.backup.html.

Actually, the "MIXED" setting will not cause the problem like "STATEMENT" does--see http://dev.mysql.com/doc/refman/5.7/en/replication-formats.html for an explanation.