Movatterモバイル変換

MySQL 5.7 Reference Manual

5.4.4.3 Mixed Binary Logging Format

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

When a DML statement updates anNDBCLUSTER table.
When a function containsUUID().
When one or more tables withAUTO_INCREMENT columns are updated and a trigger or stored function is invoked. Like all other unsafe statements, this generates a warning ifbinlog_format = STATEMENT.
For more information, seeSection 16.4.1.1, “Replication and AUTO_INCREMENT”.
When the body of a view requires row-based replication, the statement creating the view also uses it. For example, this occurs when the statement creating a view uses theUUID() function.
When a call to a loadable function is involved.
If a statement is logged by row and the session that executed the statement has any temporary tables, logging by row is used for all subsequent statements (except for those accessing temporary tables) until all temporary tables in use by that session are dropped.
This is true whether or not any temporary tables are actually logged.
Temporary tables cannot be logged using row-based format; thus, once row-based logging is used, all subsequent statements using that table are unsafe. The server approximates this condition by treating all statements executed during the session as unsafe until the session no longer holds any temporary tables.
WhenFOUND_ROWS() orROW_COUNT() is used. (Bug #12092, Bug #30244)
WhenUSER(),CURRENT_USER(), orCURRENT_USER is used. (Bug #28086)
When a statement refers to one or more system variables. (Bug #31168)
Exception. The following system variables, when used with session scope (only), do not cause the logging format to switch:
For information about determining system variable scope, seeSection 5.1.8, “Using System Variables”.
For information about how replication treatssql_mode, seeSection 16.4.1.37, “Replication and Variables”.
When one of the tables involved is a log table in themysql database.
When theLOAD_FILE() function is used. (Bug #39701)

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 ofSHOW WARNINGS) and through themysqld error log. A warning is added to theSHOW 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 berow-logging capable.
If an engine supports statement-based logging, the engine is said to bestatement-logging capable.

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

Storage Engine	Row Logging Supported	Statement Logging Supported
`ARCHIVE`	Yes	Yes
`BLACKHOLE`	Yes	Yes
`CSV`	Yes	Yes
`EXAMPLE`	Yes	No
`FEDERATED`	Yes	Yes
`HEAP`	Yes	Yes
`InnoDB`	Yes	Yes when the transaction isolation level is`REPEATABLE READ` or`SERIALIZABLE`; No otherwise.
`MyISAM`	Yes	Yes
`MERGE`	Yes	Yes
`NDB`	Yes	No

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, orMIXED), 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 usingROW 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.Type,binlog_format,SLC, andRLC columns outline the conditions, andError / Warning andLogged as columns represent the corresponding actions.SLC stands for“statement-logging capable”, andRLC stands for“row-logging capable”.

Type	`binlog_format`	SLC	RLC	Error / Warning	Logged as
*	`*`	No	No	Error: Cannot execute statement: Binary logging is impossible since at least one engine is involved that is both row-incapable and statement-incapable.	`-`
Safe	`STATEMENT`	Yes	No	-	`STATEMENT`
Safe	`MIXED`	Yes	No	-	`STATEMENT`
Safe	`ROW`	Yes	No	Error: 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.	`-`
Unsafe	`STATEMENT`	Yes	No	Warning: Unsafe statement binlogged in statement format, since`BINLOG_FORMAT = STATEMENT`	`STATEMENT`
Unsafe	`MIXED`	Yes	No	Error: 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`.	`-`
Unsafe	`ROW`	Yes	No	Error: 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 Injection	`STATEMENT`	Yes	No	Error: 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 Injection	`MIXED`	Yes	No	Error: 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 Injection	`ROW`	Yes	No	Error: 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.	-
Safe	`STATEMENT`	No	Yes	Error: 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.	`-`
Safe	`MIXED`	No	Yes	-	`ROW`
Safe	`ROW`	No	Yes	-	`ROW`
Unsafe	`STATEMENT`	No	Yes	Error: 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.	-
Unsafe	`MIXED`	No	Yes	-	`ROW`
Unsafe	`ROW`	No	Yes	-	`ROW`
Row Injection	`STATEMENT`	No	Yes	Error: Cannot execute row injection: Binary logging is not possible since`BINLOG_FORMAT = STATEMENT`.	`-`
Row Injection	`MIXED`	No	Yes	-	`ROW`
Row Injection	`ROW`	No	Yes	-	`ROW`
Safe	`STATEMENT`	Yes	Yes	-	`STATEMENT`
Safe	`MIXED`	Yes	Yes	-	`STATEMENT`
Safe	`ROW`	Yes	Yes	-	`ROW`
Unsafe	`STATEMENT`	Yes	Yes	Warning: Unsafe statement binlogged in statement format since`BINLOG_FORMAT = STATEMENT`.	`STATEMENT`
Unsafe	`MIXED`	Yes	Yes	-	`ROW`
Unsafe	`ROW`	Yes	Yes	-	`ROW`
Row Injection	`STATEMENT`	Yes	Yes	Error: Cannot execute row injection: Binary logging is not possible because`BINLOG_FORMAT = STATEMENT`.	-
Row Injection	`MIXED`	Yes	Yes	-	`ROW`
Row Injection	`ROW`	Yes	Yes	-	`ROW`

When a warning is produced by the determination, a standard MySQL warning is produced (and is available usingSHOW WARNINGS). The information is also written to themysqld 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.

Iflog_error_verbosity is 2 or greater on a replica, the replica 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.

PREV HOME UP NEXT