Major changes in the replication environment and in the behavior of applications can result from using row-based logging (RBL) or row-based replication (RBR) rather than statement-based logging or replication. This section describes a number of issues known to exist when using row-based logging or replication, and discusses some best practices for taking advantage of row-based logging and replication.
For additional information, see Section 16.1.2, “Replication Formats”, and Section 18.104.22.168, “Advantages and Disadvantages of Statement-Based and Row-Based Replication”.
For information about issues specific to MySQL Cluster Replication (which depends on row-based replication), see Section 17.6.3, “Known Issues in MySQL Cluster Replication”.
RBL, RBR, and temporary tables. As noted in Section 22.214.171.124, “Replication and Temporary Tables”, temporary tables are not replicated when using row-based format. When mixed format is in effect, “safe” statements involving temporary tables are logged using statement-based format. For more information, see Section 126.96.36.199, “Advantages and Disadvantages of Statement-Based and Row-Based Replication”.
Temporary tables are not replicated when using row-based format because there is no need. In addition, because temporary tables can be read only from the thread which created them, there is seldom if ever any benefit obtained from replicating them, even when using statement-based format.
RBL and synchronization of nontransactional tables. When many rows are affected, the set of changes is split into several events; when the statement commits, all of these events are written to the binary log if the statement is an initial nontransactional statement (occurring in the transaction before any transactional statements). When executing on the slave, a table lock is taken on all tables involved, and then the rows are applied in batch mode. (This may or may not be effective, depending on the engine used for the slave's copy of the table.)
Latency and binary log size. Because RBL writes changes for each row to the binary log, its size can increase quite rapidly. In a replication environment, this can significantly increase the time required to make changes on the slave that match those on the master. You should be aware of the potential for this delay in your applications.
Reading the binary log.
mysqlbinlog displays row-based events
in the binary log using the
statement (see Section 188.8.131.52, “BINLOG Syntax”). This statement
displays an event in printable form, but as a base
64-encoded string the meaning of which is not evident. As
of MySQL 5.1.28, when invoked with the
mysqlbinlog formats the contents of the
binary log in a manner that is easily human readable. This
is helpful when binary log events were written in
row-based format if you want to read or recover from a
replication or database failure using the contents of the
binary log. For more information, see
Section 184.108.40.206, “mysqlbinlog Row Event Display”.
Binary log execution errors and slave_exec_mode.
IDEMPOTENT, a failure to apply changes
from RBL because the original row cannot be found does not
trigger an error or cause replication to fail. This means
that it is possible that updates are not applied on the
slave, so that the master and slave are no longer
synchronized. Latency issues and use of nontransactional
tables with RBR when
IDEMPOTENT can cause the master and
slave to diverge even further. For more information about
Section 5.1.4, “Server System Variables”.
is generally useful only for circular replication or
multi-master replication with MySQL Cluster, for which
IDEMPOTENT is the default value (see
Section 17.6, “MySQL Cluster Replication”).
Lack of binary log checksums.
RBL uses no checksums. This means that network, disk, and
other errors may not be identified when processing the
binary log. To ensure that data is transmitted without
network corruption, you may want to consider using SSL,
which adds another layer of checksumming, for replication
TO statement has options to enable replication
over SSL. See also Section 220.127.116.11, “CHANGE MASTER TO Syntax”, for
general information about setting up MySQL with SSL.
Filtering based on server ID not supported.
A common practice is to filter out changes on some slaves
by using a
WHERE clause that includes
DELETE statements, a simple
example of such a clause being
<> 1. However, this does not work
correctly with row-based logging. If you must use the
server_id system variable
for statement filtering, you must also use
Database-level replication options.
The effects of the
options differ considerably depending on whether row-based
or statement-based logging is used. Because of this, it is
recommended to avoid database-level options and instead
use table-level options such as
For more information about these options and the impact
that your choice of replication format has on how they
operate, see Section 16.1.3, “Replication and Binary Logging Options and Variables”.
RBL, nontransactional tables, and stopped slaves.
When using row-based logging, if the slave server is
stopped while a slave thread is updating a
nontransactional table, the slave database may reaches an
inconsistent state. For this reason, it is recommended
that you use a transactional storage engine such as
InnoDB for all tables
replicated using the row-based format.
STOP SLAVE (or
SQL_THREAD in MySQL 5.1.55 and later) prior to
shutting down the slave MySQL server helps prevent such
issues from occurring, and is always recommended regardless
of the logging format or storage engines employed.