MySQL Bugs: #71864: Binlog info seems outdated

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:	None
Category:	MySQL Enterprise Backup Documentation	Severity:	S3 (Non-critical)
Version:	3.9.0	OS:	Any
Assigned to:	Daniel So	CPU Architecture:	Any

Description:
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

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...

Hello Daniel,

Thank you for the bug report.

Thanks,
Umesh

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.

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.

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.

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.