When speaking of the “safeness” of a statement in MySQL Replication, we are referring to whether a statement and its effects can be replicated correctly using statement-based format. If this is true of the statement, we refer to the statement as safe; otherwise, we refer to it as unsafe.
In general, a statement is safe if it deterministic, and unsafe if it is not. However, certain nondeterministic functions are not considered unsafe (see Nondeterministic functions not considered unsafe, later in this section). In addition, statements using results from floating-point math functions—which are hardware-dependent—are always considered safe (see Section 184.108.40.206, “Replication and Floating-Point Values”).
Handling of safe and unsafe statements.
A statement is treated differently depending on whether the
statement is considered safe, and with respect to the binary
logging format (that is, the current value of
No distinction is made in the treatment of safe and unsafe
statements when the binary logging mode is
If the binary logging format is
statements flagged as unsafe are logged using the row-based
format; statements regarded as safe are logged using the
If the binary logging format is
STATEMENT, statements flagged as being
unsafe generate a warning to this effect. (Safe statements
are logged normally.)
For more information, see Section 16.1.2, “Replication Formats”.
Statements containing system functions that may return a different value
These functions include
In MySQL 5.1.43 and later,
RAND() is also treated as
unsafe. (Bug #11757207, Bug #49222)
Nondeterministic functions not considered unsafe.
Although these functions are not deterministic, they are
treated as safe for purposes of logging and replication:
For more information, see Section 220.127.116.11, “Replication and System Functions”.
References to system variables. Most system variables are not replicated correctly using the statement-based format. For exceptions, see Section 18.104.22.168, “Mixed Binary Logging Format”.
UDFs. Since we have no control over what a UDF does, we must assume that it is executing unsafe statements.
Updates a table having an
This is unsafe because the order in which the rows are
updated may differ on the master and the slave.
In addition, an
INSERT into a
table that has a composite primary key containing an
AUTO_INCREMENT column that is not the
first column of this composite key is unsafe.
For more information, see
Section 22.214.171.124, “Replication and
INSERT DELAYED statement.
This statement is considered unsafe because the insertion
of the rows may interleave with concurrently executing
INSERT ... ON
DUPLICATE KEY UPDATE statements on tables with
multiple primary or unique keys.
When executed against a table that contains more than one
primary or unique key, this statement is considered
unsafe, being sensitive to the order in which the storage
engine checks the keys, which is not deterministic, and on
which the choice of rows updated by the MySQL Server
Thus, such statements are considered unsafe.
The order in which rows are retrieved is not specified.
Accesses or references log tables. The contents of the system log table may differ between master and slave.
Nontransactional operations after transactional operations. Within a transaction, allowing any nontransactional reads or writes to execute after any transactional reads or writes is considered unsafe.
For more information, see Section 126.96.36.199, “Replication and Transactions”.
Accesses or references self-logging tables. All reads and writes to self-logging tables are considered unsafe. Within a transaction, any statement following a read or write to self-logging tables is also considered unsafe.
LOAD DATA INFILE
Beginning with MySQL 5.1.50,
INFILE is considered unsafe, it causes a warning
in statement-based mode, and a switch to row-based format
when using mixed-format logging. See
Section 188.8.131.52, “Replication and
For additional information, see Section 16.4.1, “Replication Features and Issues”.