MySQL uses statement-based logging (SBL), row-based logging (RBL) or mixed-format logging. The type of binary log used impacts the size and efficiency of logging. Therefore the choice between row-based replication (RBR) or statement-based replication (SBR) depends on your application and environment. This section describes known issues when using a row-based format log, and discusses some best practices using it in replication.
For additional information, see Section 2.2, “Replication Formats”, and Section 2.2.1, “Advantages and Disadvantages of Statement-Based and Row-Based Replication”.
For information about issues specific to NDB Cluster Replication (which depends on row-based replication), see Known Issues in NDB Cluster Replication.
Row-based logging of temporary tables. As noted in Section 4.1.29, “Replication and Temporary Tables”, temporary tables are not replicated when using row-based format. When using mixed format logging, “safe” statements involving temporary tables are logged using statement-based format. For more information, see Section 2.2.1, “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.
In MySQL 5.6, you can switch from statement-based to row-based binary logging mode even when temporary tables have been created. However, while using the row-based format, the MySQL server cannot determine the logging mode that was in effect when a given temporary table was created. For this reason, the server in such cases logs a
DROP TEMPORARY TABLE IF EXISTSstatement for each temporary table that still exists for a given client session when that session ends. While this means that it is possible that an unnecessary
DROP TEMPORARY TABLEstatement might be logged in some cases, the statement is harmless, and does not cause an error even if the table does not exist, due to the presence of the
From MySQL 8.0, this behavior is changed because the MySQL server tracks the logging mode that was in effect when each temporary table was created. The
DROP TEMPORARY TABLE IF EXISTSstatement is therefore not necessarily logged for each temporary table. From that release, when a given client session ends, the server logs a
DROP TEMPORARY TABLE IF EXISTSstatement for each temporary table that still exists and was created when statement-based binary logging was in use. If row-based or mixed format binary logging was in use when the table was created, the
DROP TEMPORARY TABLE IF EXISTSstatement is not logged.
Nontransactional DML statements involving temporary tables are allowed when using
binlog_format=ROW, as long as any nontransactional tables affected by the statements are temporary tables (Bug #14272672).
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. When executing on the replica, 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 replica's copy of the table.)
Latency and binary log size. RBL writes changes for each row to the binary log and so its size can increase quite rapidly. This can significantly increase the time required to make changes on the replica that match those on the source. 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
BINLOGstatement (see BINLOG Statement). This statement displays an event as a base 64-encoded string, the meaning of which is not evident. When invoked with the
--verboseoptions, mysqlbinlog formats the contents of the binary log to be human readable. When binary log events were written in row-based format and you want to read or recover from a replication or database failure you can use this command to read contents of the binary log. For more information, see mysqlbinlog Row Event Display.
Binary log execution errors and slave_exec_mode. If
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 replica, so that the source and replica are no longer synchronized. Latency issues and use of nontransactional tables with RBR when
IDEMPOTENTcan cause the source and replica to diverge even further. For more information about
slave_exec_mode, see Server System Variables.Note
slave_exec_mode=IDEMPOTENTis generally useful only for circular replication or multi-source replication with NDB Cluster, for which
IDEMPOTENTis the default value.
For other scenarios, setting
STRICTis normally sufficient; this is the default value.Note
Formerly, the default value when using NDB Cluster was
slave_exec_mode=IDEMPOTENT, but this is no longer the case in MySQL NDB Cluster 7.3 and later.
Filtering based on server ID not supported. In MySQL 5.6, you can filter based on server ID by using the
IGNORE_SERVER_IDSoption for the
CHANGE MASTER TOstatement. This option works with statement-based and row-based logging formats. Another method to filter out changes on some replicas is to use a
WHEREclause that includes the relation
@@server_id <>clause with
DELETEstatements. For example,
WHERE @@server_id <> 1. However, this does not work correctly with row-based logging. To use the
server_idsystem variable for statement filtering, use statement-based logging.
Database-level replication options. The effects of the
--replicate-rewrite-dboptions differ considerably depending on whether row-based or statement-based logging is used. Therefore, it is recommended to avoid database-level options and instead use table-level options such as
--replicate-ignore-table. For more information about these options and the impact replication format has on how they operate, see Section 2.4, “Replication and Binary Logging Options and Variables”.
RBL, nontransactional tables, and stopped replicas. When using row-based logging, if the replica server is stopped while a replication thread is updating a nontransactional table, the replica database can reach an inconsistent state. For this reason, it is recommended that you use a transactional storage engine such as
InnoDBfor all tables replicated using the row-based format. Use of
STOP SLAVE SQL_THREADprior to shutting down the replica MySQL server helps prevent issues from occurring, and is always recommended regardless of the logging format or storage engine you use.