First, execute the sart slave command on the slave server to turn on the master-slave copy switch, start the master-slave replication.
At this point, the IO thread of the slave server connects to the master server by requesting a copy user right that is already authorized on master, and requests that the Binlog log file be executed from the specified location (the log file name and location are the change that is performed when the master-slave Replication Service is configured The Binlog log content is sent after the master command has been specified
Third, after the master server receives the request from the IO thread from the slave server, the binary dump IO thread reads the Binlog log information after the specified Binlog log file is specified in batches based on the information requested by the IO thread of the slave server. The IO thread is then returned to the slave side. In addition to the Binlog log content, the returned information has a new Binlog file name recorded on the master server side, and the next specified update location in the new Binlog.
Iv. when the IO thread of the slave server acquires the log content, log files, and location points sent by the IO thread on the master server, the Binlog log contents are written sequentially to the relay of the slave side itself The terminal of the log (that is, the trunk log) file (mysql-relay-bin.xxx), and records the new Binlog file name and location to the Master-info file so that the next time you read the new Binlog log on the master, you can tell the master server to specify from new Binlog log File and location start to read new Binlog log content
V. Slave server-side SQL thread detects the new log content of the IO thread in the local relay log in real time, then parses the contents of the relay log file into SQL statements and executes the SQL statements in the order in which the SQL statements are parsed on their own slave server , and record the file name and location point of the current application's relay log in Relay-log.info