The world's most popular open source database
[+/-]
Replication works because events written to the binary log are read from the master and then processed on the slave. The events are recorded within the binary log in different formats according the type of event being recorded. The different replication formats used correspond to the binary logging format used when the events were recorded in the master's binary log. The correlation between binary logging formats and the terms used during replication are:
Replication capabilities in MySQL originally were based on propagation of SQL statements from master to slave. This is called statement-based replication (often abbreviated as SBR), which corresponds to the standard statement-based binary logging format. In older versions of MySQL (5.1.4 and earlier), binary logging and replication used this format exclusively.
Row-based binary logging logs changes in individual table rows. When used with MySQL replication, this is known as row-based replication (often abbreviated as RBR). In row-based replication, the master writes messages known as events to the binary log that indicate how individual table rows are changed.
The binary logging format can be changed in real time according to the event being logged using mixed-format logging.
When the mixed format is in effect, statement-based logging is used by default, but automatically switches to row-based logging in particular cases as described below. Replication using the mixed format is often referred to as mixed-based replication or mixed-format replication. For more information, see Section 5.2.4.3, “Mixed Binary Logging Format”.
The mixed format is the default for MySQL replication.
The binary logging format is determined in part by the storage engine being used and the statement being executed. For more information on mixed-format logging and the rules governing the support of different logging formats, see Section 5.2.4.3, “Mixed Binary Logging Format”.
You must have the SUPER privilege
to set the binary logging format on the global level. Starting
with MySQL 6.0.8, you must also have the
SUPER privilege to set the binary
logging format for the current session. (Bug#39106)
The statement-based and row-based replication formats have different issues and limitations. For a comparison of their relative advantages and disadvantages, see Section 15.1.2.1, “Comparison of Statement-Based and Row-Based Replication”.
With statement-based replication, you may encounter issues with replicating stored routines or triggers. You can avoid these issues by using row-based replication instead. For more information, see Section 17.6, “Binary Logging of Stored Programs”.
If you build MySQL from source, row-based replication is available
by default unless you invoke configure with the
--without-row-based-replication option.
For MySQL 5.1.20 and later (and MySQL 5.0.46 for backwards compatibility), the following session variables are written to the binary log and honored by the replication slave when parsing the binary log:
FOREIGN_KEY_CHECKS
UNIQUE_CHECKS
SQL_AUTO_IS_NULL
Even though session variables relating to character sets and collations are written to the binary log, replication between different character sets is not supported.


User Comments
Add your own comment.