Now that you’re familiar with the binary log, and we’ve hinted at how the binary log might beused in replication, let’s look at the steps that happen when data is replicated to another server:

1. INSERT, UPDATE, DELETE or some other data-changing query is issued to the masterdatabase.
2. The query is parsed, executed, and written to the binary log on the master.
3. The I/O thread on the slave asks for new queries from the I/O thread on the master,and pulls anything new from the binary log on the master into a log on the slave calledthe relay log.
4. A processing thread on the slave reads the relay log and executes the query.

The simple explanation is that for any data change on the master, an entry is made intothe binary log. That statement is copied to the slave and executed there as well, making theexact change to the slave as was made on the master and thus keeping the data in sync.

We hinted at different threads in these four steps. Running a replication slave requiresthree threads, in addition to those already used to keep your database’s non-replication-related features running. Two threads run on the slave, the first to communicate with themaster for entries in the master’s binary log and to pull the statements onto the slavemachine. The second slave thread reads the queries in the relay log (which were pulled fromthe master) and processes them. The third thread runs on the master and is responsible forcommunicating changes in the master’s binary log. If you have multiple slaves pointing at asingle master, the master will run a separate thread to communicate with each of the slaves.