The world's most popular open source database
The default binary logging format depends on the version of MySQL you are using:
For MySQL 5.1.11 and earlier, statement-based logging is used by default.
For MySQL 5.1.12 and later, mixed logging is used by default.
You can force the replication format by starting the MySQL
server with
--binlog-format=.
When set, all replication slaves connecting to the server will
read the events according to this setting. The supported
values for typetype are:
ROW causes replication to be
row-based.
STATEMENT causes replication to be
statement-based. This is the default for MySQL 5.1.11
and earlier, and MySQL 5.1.29 and later.
MIXED causes replication to use mixed
format. This is the default for MySQL 5.1.12 to 5.1.28.
The logging format also can be switched at runtime. To specify
the format globally for all clients, set the global value of
the binlog_format system variable. (To
change a global variable you need the
SUPER privilege.)
To switch to statement-based format, use either of these statements:
mysql>SET GLOBAL binlog_format = 'STATEMENT';mysql>SET GLOBAL binlog_format = 1;
To switch to row-based format, use either of these statements:
mysql>SET GLOBAL binlog_format = 'ROW';mysql>SET GLOBAL binlog_format = 2;
To switch to mixed format, use either of these statements:
mysql>SET GLOBAL binlog_format = 'MIXED';mysql>SET GLOBAL binlog_format = 3;
An individual client can control the logging format for its
own statements by setting the session value of
binlog_format. For example:
mysql>SET SESSION binlog_format = 'STATEMENT';mysql>SET SESSION binlog_format = 'ROW';mysql>SET SESSION binlog_format = 'MIXED';
In addition to switching the logging format manually, a slave
server may switch the format
automatically. This happens when the
server is running in either STATEMENT or
MIXED format and encounters a row in the
binary log that is written in ROW logging
format. In that case, the slave switches to row-based
replication temporarily for that event, and switches back to
the previous format afterwards.
There are two reasons why you might want to set replication logging on a per-connection basis:
A thread that makes many small changes to the database
might want to use row-based logging. A thread that
performs updates that match many rows in the
WHERE clause might want to use
statement-based logging because it will be more efficient
to log a few statements than many rows.
Some statements require a lot of execution time on the master, but result in just a few rows being modified. It might therefore be beneficial to replicate them using row-based logging.
There are exceptions when you cannot switch the replication format at runtime:
From within a stored function or a trigger.
If NDB is enabled.
If the session is currently in row-based replication mode and has open temporary tables.
Trying to switch the format in any of these cases results in an error.
Switching the replication format at runtime is not recommended
when any temporary tables exist, because temporary tables are
logged only when using statement-based replication, whereas
with row-based replication they are not logged. With mixed
replication, temporary tables are usually logged; exceptions
happen with user-defined functions (UDFs) and with the
UUID() function.
With the binlog format set to ROW, many
changes are written to the binary log using the row-based
format. Some changes, however, still use the statement-based
format. Examples include all DDL (data definition language)
statements such as CREATE
TABLE, ALTER TABLE,
or DROP TABLE.
The --binlog-row-event-max-size option is
available for servers that are capable of row-based
replication. Rows are stored into the binary log in chunks
having a size in bytes not exceeding the value of this option.
The value must be a multiple of 256. The default value is
1024.
When using statement-based logging in a replication scenario, it is possible for the data on the master and slave to become different if a statement is designed in such a way that the data modification is non-deterministic; that is, it is left to the will of the query optimizer. In general, this is not a good practice even outside of replication. For a detailed explanation of this issue, see Section B.1.8.1, “Open Issues in MySQL”.


User Comments
Add your own comment.