Documentation Home
MySQL 5.7 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 35.3Mb
PDF (A4) - 35.5Mb
PDF (RPM) - 33.8Mb
EPUB - 8.6Mb
HTML Download (TGZ) - 8.4Mb
HTML Download (Zip) - 8.5Mb
HTML Download (RPM) - 7.3Mb
Eclipse Doc Plugin (TGZ) - 9.3Mb
Eclipse Doc Plugin (Zip) - 11.3Mb
Man Pages (TGZ) - 197.9Kb
Man Pages (Zip) - 301.8Kb
Info (Gzip) - 3.2Mb
Info (Zip) - 3.2Mb
Excerpts from this Manual

MySQL 5.7 Reference Manual  /  ...  /  Mixed Binary Logging Format

6.4.4.3 Mixed Binary Logging Format

When running in MIXED logging format, the server automatically switches from statement-based to row-based logging under the following conditions:

Note

A warning is generated if you try to execute a statement using statement-based logging that should be written using row-based logging. The warning is shown both in the client (in the output of SHOW WARNINGS) and through the mysqld error log. A warning is added to the SHOW WARNINGS table each time such a statement is executed. However, only the first statement that generated the warning for each client session is written to the error log to prevent flooding the log.

In addition to the decisions above, individual engines can also determine the logging format used when information in a table is updated. The logging capabilities of an individual engine can be defined as follows:

  • If an engine supports row-based logging, the engine is said to be row-logging capable.

  • If an engine supports statement-based logging, the engine is said to be statement-logging capable.

A given storage engine can support either or both logging formats. The following table lists the formats supported by each engine.

Storage EngineRow Logging SupportedStatement Logging Supported
ARCHIVEYesYes
BLACKHOLEYesYes
CSVYesYes
EXAMPLEYesNo
FEDERATEDYesYes
HEAPYesYes
InnoDBYesYes when the transaction isolation level is REPEATABLE READ or SERIALIZABLE; No otherwise.
MyISAMYesYes
MERGEYesYes
NDBYesNo

Whether a statement is to be logged and the logging mode to be used is determined according to the type of statement (safe, unsafe, or binary injected), the binary logging format (STATEMENT, ROW, or MIXED), and the logging capabilities of the storage engine (statement capable, row capable, both, or neither). (Binary injection refers to logging a change that must be logged using ROW format.)

Statements may be logged with or without a warning; failed statements are not logged, but generate errors in the log. This is shown in the following decision table, where SLC stands for statement-logging capable and RLC stands for row-logging capable.

ConditionAction
Typebinlog_formatSLCRLCError / WarningLogged as
**NoNoError: Cannot execute statement: Binary logging is impossible since at least one engine is involved that is both row-incapable and statement-incapable.-
SafeSTATEMENTYesNo-STATEMENT
SafeMIXEDYesNo-STATEMENT
SafeROWYesNoError: Cannot execute statement: Binary logging is impossible since BINLOG_FORMAT = ROW and at least one table uses a storage engine that is not capable of row-based logging.-
UnsafeSTATEMENTYesNoWarning: Unsafe statement binlogged in statement format, since BINLOG_FORMAT = STATEMENTSTATEMENT
UnsafeMIXEDYesNoError: Cannot execute statement: Binary logging of an unsafe statement is impossible when the storage engine is limited to statement-based logging, even if BINLOG_FORMAT = MIXED.-
UnsafeROWYesNoError: Cannot execute statement: Binary logging is impossible since BINLOG_FORMAT = ROW and at least one table uses a storage engine that is not capable of row-based logging.-
Row InjectionSTATEMENTYesNoError: Cannot execute row injection: Binary logging is not possible since at least one table uses a storage engine that is not capable of row-based logging.-
Row InjectionMIXEDYesNoError: Cannot execute row injection: Binary logging is not possible since at least one table uses a storage engine that is not capable of row-based logging.-
Row InjectionROWYesNoError: Cannot execute row injection: Binary logging is not possible since at least one table uses a storage engine that is not capable of row-based logging.-
SafeSTATEMENTNoYesError: Cannot execute statement: Binary logging is impossible since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine that is not capable of statement-based logging.-
SafeMIXEDNoYes-ROW
SafeROWNoYes-ROW
UnsafeSTATEMENTNoYesError: Cannot execute statement: Binary logging is impossible since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine that is not capable of statement-based logging.-
UnsafeMIXEDNoYes-ROW
UnsafeROWNoYes-ROW
Row InjectionSTATEMENTNoYesError: Cannot execute row injection: Binary logging is not possible since BINLOG_FORMAT = STATEMENT.-
Row InjectionMIXEDNoYes-ROW
Row InjectionROWNoYes-ROW
SafeSTATEMENTYesYes-STATEMENT
SafeMIXEDYesYes-STATEMENT
SafeROWYesYes-ROW
UnsafeSTATEMENTYesYesWarning: Unsafe statement binlogged in statement format since BINLOG_FORMAT = STATEMENT.STATEMENT
UnsafeMIXEDYesYes-ROW
UnsafeROWYesYes-ROW
Row InjectionSTATEMENTYesYesError: Cannot execute row injection: Binary logging is not possible because BINLOG_FORMAT = STATEMENT.-
Row InjectionMIXEDYesYes-ROW
Row InjectionROWYesYes-ROW

When a warning is produced by the determination, a standard MySQL warning is produced (and is available using SHOW WARNINGS). The information is also written to the mysqld error log. Only one error for each error instance per client connection is logged to prevent flooding the log. The log message includes the SQL statement that was attempted.

If a slave server was started with log_error_verbosity set to display warnings, the slave prints messages to the error log to provide information about its status, such as the binary log and relay log coordinates where it starts its job, when it is switching to another relay log, when it reconnects after a disconnect, statements that are unsafe for statement-based logging, and so forth.


User Comments
  Posted by Peter Burns on March 28, 2014
It took me a while to understand the statement "Temporary tables cannot be logged using row-based format; thus, once row-based logging is used, all subsequent statements using that table are unsafe". I think it's describing the situation where a temporary table is updated with an unsafe query: in this case, the unsafe update can't be logged row-based, and all subsequent statements using that table are indeed unsafe. However, this understanding conflicts with the earlier statement that "logging by row is used for all subsequent statements (except for those accessing temporary tables)": surely it's *only* the statements using temporary tables which now need to be logged by row?

The rule to approximate this condition ("treating all statements executed during the session as unsafe until the session no longer holds any temporary tables") causes us some problems when we try to use MIXED replication, because
a) we run multiple servers in a replication loop and
b) the rule seems to be applied to the slave SQL thread, i.e. the statements executed by this thread are treated as a single session

So what we see is this (with MIXED replication everywhere):
1. a session on the master creates a temporary table (logged by statement)
2. another session on the master logs by row (e.g. because it's unsafe)
3. other sessions on the master log by statement
4. but when these statement-logged events replicate to the slave, they now get logged by row (until the temporary table is dropped)

Hence statements safe for SBR but unsafe for RBR (see my comment on http://dev.mysql.com/doc/refman/5.1/en/replication-sbr-rbr.html) can get logged by row and cause problems further down the replication chain. Disaster!

I think the easiest solution is to always log by row when using temporary tables ("SET SESSION binlog_format='ROW'"). But it would be good to have an option to do this automatically in MIXED mode, e.g. to always treat statements using temporary tables as unsafe.

  Posted by Scott M. Sanders on August 19, 2014
If you need it mixed but are not a SUPER user, do this first instead:
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
Sign Up Login You must be logged in to post a comment.