The default replication format depends on the version of MySQL you are using:
For MySQL 5.1.11 and earlier, statement-based replication is used by default.
For MySQL 5.1.12 and later, mixed-based replication is used by default.
You can force the default replication format by specifying the
format type to the
--binlog-format=
option. When set, all replication slaves connecting to the
server will read the events according to this setting. The
supported options are:
type
ROW — sets row-based replication
as the default.
STATEMENT — sets statement-based
replication as the default. This is the default for MySQL
5.1.11 and earlier.
MIXED — sets mixed-based
replication as the default. This is the default for MySQL
5.1.12 and later.
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;
Individual clients can control the logging format for their 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 those 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 (UDF) 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 row-based replication 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.