Mixing transactional and nontransactional statements within the same transaction. In general, you should avoid transactions that update both transactional and nontransactional tables in a replication environment. You should also avoid using any statement that accesses both transactional (or temporary) and nontransactional tables and writes to any of them.
As of MySQL 5.1.44, the server uses these rules for binary logging:
If the initial statements in a transaction are nontransactional, they are written to the binary log immediately. The remaining statements in the transaction are cached and not written to the binary log until the transaction is committed. (If the transaction is rolled back, the cached statements are written to the binary log only if they make nontransactional changes that cannot be rolled back. Otherwise, they are discarded.)
For statement-based logging, logging of nontransactional
statements is affected by the
system variable. When this variable is
OFF (the default), logging is as just
described. When this variable is
logging occurs immediately for nontransactional statements
occurring anywhere in the transaction (not just initial
nontransactional statements). Other statements are kept in
the transaction cache and logged when the transaction
has no effect for row-format or mixed-format binary logging.
Transactional, nontransactional, and mixed statements. To apply those rules, the server considers a statement nontransactional if it changes only nontransactional tables, and transactional if it changes only transactional tables. A statement that changes both nontransactional and transactional tables is considered “mixed”. Mixed statements, like transactional statements, are cached and logged when the transaction commits.
A mixed statement is unrelated to mixed binary logging format.
Before MySQL 5.1.44, the rules for binary logging are similar to
those just described, except that there is no
system variable to affect logging of transactional statements.
Thus, the server immediately logs only the initial
nontransactional statements in a transaction and caches the rest
until commit time.
Before MySQL 5.1.31, the effect of the rules differs because the definition of transactional statement is different: In these earlier versions, a statement is nontransactional if the first changes it makes change nontransactional tables, transactional if the first changes it makes change transactional tables. “First” applies in the sense that a statement may have several effects if it involves such things as triggers, stored functions, or multiple-table updates. A mixed statement that changes both nontransactional and transactional tables is handled as nontransactional or transactional depending on the type of changes it makes first.
In situations where transactions mix updates to transactional
and nontransactional tables, the order of statements in the
binary log is correct, and all needed statements are written to
the binary log even in case of a
However, when a second connection updates the nontransactional
table before the first connection transaction is complete,
statements can be logged out of order because the second
connection update is written immediately after it is performed,
regardless of the state of the transaction being performed by
the first connection.
Using different storage engines on master and slave.
It is possible to replicate transactional tables on the master
using nontransactional tables on the slave. For example, you
can replicate an
InnoDB master table as a
MyISAM slave table. However, if you do
this, there are problems if the slave is stopped in the middle
COMMIT block because the
slave restarts at the beginning of the
Beginning with MySQL 5.1.48, it is also safe to replicate
MyISAM tables on
the master to transactional tables—such as tables that use
InnoDB storage engine—on
the slave. In such cases (beginning with MySQL 5.1.48), an
statement issued on the master is replicated, thus enforcing
AUTOCOMMIT mode on the slave.
When the storage engine type of the slave is nontransactional, transactions on the master that mix updates of transactional and nontransactional tables should be avoided because they can cause inconsistency of the data between the master transactional table and the slave nontransactional table. That is, such transactions can lead to master storage engine-specific behavior with the possible effect of replication going out of synchrony. MySQL does not issue a warning about this currently, so extra care should be taken when replicating transactional tables from the master to nontransactional tables on the slaves.
Beginning with MySQL Cluster NDB 6.2.14 and MySQL 5.1.24, every
autocommit transactions) is
recorded in the binary log as though it starts with a
statement, and ends with either a
COMMIT or a
statement. However, this does not apply to
nontransactional changes; any statements affecting tables using
a nontransactional storage engine such as
MyISAM are regarded for this
purpose as nontransactional, even when
autocommit is enabled. (Bug