Mysql series-replication

Replication is not a copy, but a replication. From today on, I will discuss the mysql replication issue in several chapters, the master-slave replication issues will be explained in detail separately. First, I would like to explain the mechanism of mysql replication, which is generally described as follows:
 

 
 
We can explain it in three parts.
1. The master server writes the changes to the binary log ).
2. The slave server copies the binary log file of the master server to its own relay log.
3. Replay events in the relay logs from the server and update related data.
Next we will explain in detail. When the master server updates data, including insert, create, drop, and other operations, it will write specific events into its own binary log, even if the specific operation is an incorrect operation, the related events are also written into their own binary logs, then, the slave server will take the initiative to copy the binary log file generated by the master server and write it into its own relay log. In this process, the slave server will establish an I/O thread. To put it bluntly, the slave server will establish a client connection to actively connect to the master server and then start a process, the role of this process is to read the event from the binary log of the master server. When the slave server copies the binary log file of the master server to its own relay log file, the slave server starts a thread to read the content in the relay log, and play the role of synchronizing the content in the primary database. It should be noted that mysql replication is asynchronously synchronized, which means that the data on the slave server is not updated from time to time, and there may be latency between them, which may be several seconds, A few minutes, a large database may even be a few hours. Oh, my sky !!
 
This article is from the "humbly seeking for advice" blog