MySQL's built-in replication capabilities are the foundation for building large, high-performance applications. The distribution of MySQL data across multiple systems is done by copying data from one of the MySQL hosts to the other host (slave) and re-executing it again. One server acts as the primary server during replication, while one or more other servers act as slave servers. The Primary server writes the update to the binary log file and maintains an index of the file to track the log loop. These logs can record updates that are sent to the slave server. When a server is connected to the primary server, it notifies the primary server where the last successful update was read from the server in the log. Receive any updates from the server from then on, and then block and wait for the primary server to notify the new updates.
3 Threads:
First,slave starts a worker thread -----I/O thread. The I/O thread opens a normal connection on master and then starts Binlog dump process. Binlog dump process reads the event from the binary log of master, and if it has been followed by master, it sleeps and waits for master to produce a new event. The I/O thread writes these events to the relay log.
The SQL slave thread (SQL slave thread) handles the last step of the process. The SQL thread updates the slave data from the log read event, making it consistent with the data in master. As long as the thread is consistent with the I/O thread, the trunk log is typically located in the OS cache, so the overhead of the trunk log is minimal.
In addition, there is a worker thread in master : As with other MySQL connections, slave opening a connection in master will also cause master to start a thread. The replication process has an important limitation-----replication is serialized on slave, meaning that parallel update operations on master cannot be operated concurrently on slave.
Https://dev.mysql.com/doc/refman/5.6/en/replication-implementation-details.html
MySQL replication principle and its flow