MySQL Database Master-Slave Replication Principle

1. What is master-slave replication?
1.1 Understanding master-slave replication
First of all, master-slave replication is a data backup scheme, which is used to establish a database environment that is exactly the same as the master database, called the slave database. The master database is generally a quasi-real-time business database.
Simple Application Server
USD1.00 New User Coupon
* Only 3,000 coupons available.
* Each new user can only get one coupon(except users from distributors).
* The coupon is valid for 30 days from the date of receipt.

1.2 The role of master-slave replication
Do hot backup of data:
As a backup database, after the primary database server fails, you can switch to the secondary database to continue working to avoid data loss.
Extension of the architecture:
The business volume is getting bigger and bigger, and the I/O access frequency is too high for a single machine to meet. At this time, multi-bank storage is used to reduce the frequency of disk I/O access and improve the I/O performance of a single machine.
Read and write separation:
1) Query work can be performed on the slave server to reduce the pressure on the master server (master library write, slave library read, pressure reduction);
2) Perform backup on the slave server to avoid affecting the service of the master server during the backup period; (to ensure data security).
Second, the principle of master-slave replication
To achieve master-slave replication, you must first turn on the binary log (bin-log) function of the Master server, and then turn on the I/O thread and SQL thread of the Slave server to complete it together. Because the entire MySQL replication process is actually that the Slave obtains the corresponding binary log from the Master, and then executes the various operations recorded in the log on its own slave in complete order. The following is an illustration of its working principle:
Insert picture description here

Step 1: The update events (update, insert, delete) of the main database db are written to the binlog;
Step 2: Initiate a connection from the library and connect to the main library;
Step 3: At this time, the main library creates a binlog dump thread thread and sends the contents of the binlog to the slave library;
Step 4: After starting from the library, create an I/O thread, read the binlog content from the main library and write it to the relay log;
Step 5: A SQL thread is also created to read the content from the relay log and write the updated content to the slave's db database.

In fact, it can be simply summed up in the following three points:

The main library records data changes (such as SQL statements such as DDL, DML, DCL, etc.) in the Binary Log.
The I/O thread of the standby library copies the log on the main library to its own relay log (Relay Log).
The standby database SQL thread reads the events in the relay log and replays them on the standby database.