Column address:
Article Directory
1. The principle of MySQL master-slave replication
The synchronization between the main database and the slave database of MySQL through binlog is a logical replication strategy, which mainly involves the binlog dump thread of the main database and the IO thread and SQL thread of the slave database.
The binlog dump thread of the main library and the IO thread of the slave library establish a long link when:
- When the binlog dump thread of the main library monitors the binlog file change, it notifies the IO thread of the slave library to pull;
- Initiate a request from the library IO thread and save the returned log in the relay log;
- The SQL thread from the library monitors the changes in the relay log, reads and replays them in turn.
Master-slave delay
The binlog dump thread of the main library and the IO thread of the slave library are both single-threaded. Since the binlog is written sequentially and submitted by a group, it is more efficient.
The SQL thread of the slave library is single-threaded by default, which is prone to performance bottlenecks, especially when encountering large DDL. This is to ensure that the master and slave are consistent, and parallel replay needs to ensure that the execution order between dependent transactions is consistent with the master library, and to prevent problems such as update coverage caused by reverse execution. MySQL5.7 introduced multi-threaded replication MTS (Multi-Threaded Slave), in view of the fact that there is no conflict between transactions in the same group in group submission (the two-phase lock protocol makes it impossible for transactions submitted at the same time to modify the same row), so you can Parallel replay of binlogs of multiple transactions in the same group.
The coordinator is the original SQL thread, which is now only responsible for reading logs and distributing tasks, while the worker thread is responsible for the real log replay.
Delayed calculation
2. Format of binlog
Binlog is a binary log of MySQL, which records all DML and DDL operations in the form of events, which can be used for archiving (data recovery) and replication (master-slave replication).
Binlog has three formats, statement, row and mixed.
- statement: Record the original SQL statement and some context information (such as the timestamp when the now function is executed).
- Advantages: small footprint
- Disadvantages: The same statement may still produce different results when executed on the slave library. For example, the DELETE operation with LIMIT uses different indexes on the master and slave respectively.
- row (recommended) : Record all the details of the row that was modified. For the rows involved in INSRET and DELETE records, record the values of all columns, and for UPDATE, record the values of all columns before and after the modification.
- Advantages: Ensure that the master and slave are consistent, and can be used for data recovery when accidentally deleted.
- Disadvantages: take up space
- mixed: mixed statement and row format, MySQL automatically selects it, and uses row format for those that may cause inconsistency between master and slave.
- Advantages: combines the advantages of statement and row
The row format is recommended for data recovery.
mysqldump and mysqlbinlog can make full and incremental binlogs.
reference
"45 Lectures on MySQL Actual Combat"