Setting The Binary Log Format
You can select the binary logging format explicitly by starting the MariaDB server with --binlog-format=
. The supported values for type
type
are:
STATEMENT
causes logging to be statement based.ROW
causes logging to be row based.MIXED
causes logging to use mixed format.
In MariaDB 5.6, the default binary logging format is STATEMENT
.
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:
mysql>SET GLOBAL binlog_format = 'STATEMENT';
mysql>SET GLOBAL binlog_format = 'ROW';
mysql>SET GLOBAL binlog_format = 'MIXED';
An individual client can control the logging format for its own statements by setting the session value of binlog_format
:
mysql>NoteSET SESSION binlog_format = 'STATEMENT';
mysql>SET SESSION binlog_format = 'ROW';
mysql>SET SESSION binlog_format = 'MIXED';
Each MariaDB Server can set its own and only its own binary logging format (true whether binlog_format
is set with global or session scope). This means that changing the logging format on a replication master does not cause a slave to change its logging format to match. (When using STATEMENT
mode, the binlog_format
system variable is not replicated; when using MIXED
or ROW
logging mode, it is replicated but is ignored by the slave.) Changing the binary logging format on the master while replication is ongoing, or without also changing it on the slave can thus cause unexpected results, or even cause replication to fail altogether.
To change the global or session binlog-format
value, you must have the SUPER
privilege.
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 an event 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 afterward.
There are several reasons why a client might want to set binary logging on a per-session basis:
- A session that makes many small changes to the database might want to use row-based logging.
- A session 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 the
NDBCLUSTER
storage engine 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 binary log 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.Warning
When using statement-based logging for 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 nondeterministic; 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 "Known Issues in MySQL".
For information about logs kept by replication slaves, see , "Replication Relay and Status Logs".