MySQL master-slave replication (7)-Three MySQL replication methods: asynchronous replication, semi-synchronous replication, fully synchronous replication
MySQL version 3.23.15 introduced replication technology. The implementation of replication involves two threads, one in the Master and one in the Slave. Slave's I/O and SQL functions are used as a thread. After getting the event from the Master, apply directly without relay log. This replication method causes a large delay in the primary and backup, and may cause a large number of binary logs to not be backed up to the slave side. Starting from MySQL version 4.0.2, the slave side event reading and execution are separated into two threads, namely IO thread and SQL thread, and relay log is introduced. The IO thread reads the event and writes it to the relay log, and the SQL thread reads the event from the relay log and executes it. The above replication method is asynchronous replication: the transaction execution of the main database does not consider the synchronization progress of the standby database. If the standby database has a long delay time, when the main database goes down, data may be lost.
In MySQL 5.5, semi-synchronous replication technology is introduced: the master database needs to ensure that at least one slave database receives and writes to the relay log before responding to the transaction submitted by the client.
The concept of InnoDB Group Replication is introduced in MySQL 5.7.17, and it provides full synchronization technology based on Group replication.
The following introduces asynchronous replication, semi-synchronous replication, and fully synchronous replication:
One, asynchronous replication
MySQL's default replication is asynchronous replication. The main database returns the result to the client immediately after executing the transaction submitted by the client, and does not care whether the slave database has received and processed it. The main library writes the transaction Binlog events to the Binlog file. At this time, the main library just informs the Dump thread to send these new Binlogs, and then the main library will continue to process the commit operation. There is no guarantee that these Binlogs will be transmitted to any slave node. . There will be a problem. If the main library fails, the transaction submitted by the main library may not be transferred to the slave library, which may cause data loss.
MySQL's asynchronous replication relies on binary logs for data replication. For example, there are two machines: a master library (master) and a slave library (slave).
(1) Normal replication: Transaction one (t1) is written into the binlog buffer; the dumper thread informs the slave that there is a new transaction t1; the binlog buffer performs checkpoint; the slave's IO thread receives t1 and writes it to its own relay log; slave The SQL thread writes to the local database. In this case, both the master and slave can see this new transaction. If the master goes down, the slave can be promoted to the new master.
(2) Abnormal replication: Transaction one (t1) is written into the binlog buffer; the dumper thread informs the slave that there is a new transaction t1; the binlog buffer performs checkpoint; the slave has not received t1 because of the unstable network; if the master goes down, the slave Promote to the new master, then t1 is lost.
(3) Existing problems: the transaction update of the master database and the slave database is not synchronized, which results in inconsistent data between the slave database and the master database.
Second, full synchronous replication
After the main library commits the transaction, all slave library nodes must receive, APPLY and submit these transactions, and then the main library thread can continue to do subsequent operations. Because you need to wait for all slaves to complete the transaction before returning, the performance of full synchronous replication is bound to be severely affected.
Three, semi-synchronous replication
Between asynchronous replication and fully synchronous replication, the main library does not return to the client immediately after executing the transaction submitted by the client, but waits for at least one received from the library and written to the relay log before returning to the client. Compared with asynchronous replication, semi-synchronous replication improves data security, and it also causes a certain degree of delay.
The emergence of semi-synchronous replication is to ensure that the primary and backup data are consistent at any time. Compared with asynchronous replication, each transaction required by semi-synchronous replication requires at least one standby database to be successfully received before returning to the user. The implementation principle is also very simple. After the local execution of the main library is completed, it waits for the response message of the standby library (including the binlog (file, pos) received by the latest standby library), and then returns to the user after receiving the response message from the standby library. The transaction is truly completed. On the main library instance, there is a dedicated thread (ack_receiver) that receives the response message of the standby library, and uses the notification mechanism to inform the main library that the standby library has received the log, and can continue to execute.
The principle of semi-synchronous replication is shown in the figure below:
The process of semi-synchronous replication: the master writes each transaction to the binlog (sync_binlog=1), passes it to the slave and flushes it to disk (sync_relay=1), and the master database commits the transaction (commit). The master waits for the slave's feedback to receive the relay log, and only after receiving the ACK does the master feed back the commit OK result to the client.
Features of semi-synchronous replication:
(1) The slave library will tell the master library when it connects to the master library whether it is configured for semi-synchronization.
(2) If semi-synchronous replication is started on the main library side, and there is at least one semi-synchronous replication slave library node, then the transaction thread of the main library will be blocked and wait when committing. There are two possible results: (a ) At least one slave node informs it that it has received all the Binlog events of this transaction; (b) Waiting until a certain time point is exceeded, at this time, semi-synchronous replication will be automatically closed and converted to asynchronous replication.
(3) Only after receiving all Binlogs of a certain transaction and writing them to the Relay Log file, the slave node will notify the waiting thread on the corresponding main library.
(4) If in the waiting process, the waiting time has exceeded the configured timeout period, and no slave node has notified the current transaction, then the main library will automatically switch to asynchronous replication at this time, when at least one semi-synchronous slave node catches up , The main library will automatically switch to semi-synchronous replication.
(5) Semi-synchronous replication must be enabled when both the main library and the slave library are enabled. If it is not opened on the main library, or if it is enabled on the main library but not on the slave library, the main library will use asynchronous Way to copy.
references:
1、https://blog.csdn.net/xihuanyuye/article/details/81220524?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.edu_weight&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.edu_weight
2、https://blog.csdn.net/qq_41977453/article/details/103851419?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-5.edu_weight&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-5.edu_weight
3、https://www.cnblogs.com/zero-gg/p/9057092.html