MySQL Reference Manual for version 4.0.18.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6.3 Replication Implementation Details

Three threads are involved in replication: one on the master and two on the slave. When START SLAVE is issued, the I/O thread is created on the slave. It connects to the master and asks it to send the queries recorded in its binlogs. Then one thread is created on the master to send these binlogs. This thread is identified by Binlog Dump in SHOW PROCESSLIST output on the master. The I/O thread reads what the master Binlog Dump thread sends and simply copies it to some local files in the slave's data directory called relay logs. The last thread, the SQL thread, is created on the slave; it reads the relay logs and executes the queries it contains.

Note that the master has one thread for each currently connected slave server.

With SHOW PROCESSLIST you can know what is happening on the master and on the slave as regards replication.

The following example illustrates how the three threads show up in SHOW PROCESSLIST. The output format is that used by SHOW PROCESSLIST as of MySQL version 4.0.15, when the content of the State column was changed to be more meaningful compared to earlier versions.

On the master server, the output looks like this:

 
mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
     Id: 2
   User: root
   Host: localhost:32931
     db: NULL
Command: Binlog Dump
   Time: 94
  State: Has sent all binlog to slave; waiting for binlog to be updated
   Info: NULL

On the slave server, the output looks like this:

 
mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
     Id: 10
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 11
  State: Waiting for master to send event
   Info: NULL
*************************** 2. row ***************************
     Id: 11
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 11
  State: Has read all relay log; waiting for the slave I/O thread to update it
   Info: NULL

Here thread 2 is on the master. Thread 10 is the I/O thread on the slave. Thread 11 is the SQL thread on the slave; note that the value in the Time column can tell how late the slave is compared to the master (see section 6.8 Replication FAQ).

The following list shows the most common states you will see in the State column for the master's Binlog Dump thread. If you don't see this thread on a master server, replication is not running.

Sending binlog event to slave

Binlogs consist of events, where an event is usually a query plus some other information. The thread has read an event from the binlog and is sending it to the slave.

Finished reading one binlog; switching to next binlog

The thread has finished reading a binlog file and is opening the next one to send to the slave.

Has sent all binlog to slave; waiting for binlog to be updated

The thread has read all binary log files and is idle. It is waiting for new events to appear in the binary log as a result of new update queries being executed on the master.

Waiting to finalize termination

A very brief state that happens as the thread is stopping.

Here are the most common states you will see in the State column for the I/O thread of a slave server. Beginning with MySQL 4.1.1, this state also appears in the Slave_IO_State column of SHOW SLAVE STATUS output. This means that you can get a good view of what is happening by using only SHOW SLAVE STATUS.

Connecting to master

The thread is attempting to connect to the master.

Checking master version

A very brief state that happens just after the connection to the master is established.

Registering slave on master

A very brief state that happens just after the connection to the master is established.

Requesting binlog dump

A very brief state that happens just after the connection to the master is established. The thread sends to the master a request for the contents of its binlogs, starting from the requested binlog filename and position.

Waiting to reconnect after a failed binlog dump request

If the binlog dump request failed (due to disconnection), the thread goes into this state while it sleeps. The thread sleeps for master-connect-retry seconds before retrying.

Reconnecting after a failed binlog dump request

Then the thread tries to reconnect to the master.

Waiting for master to send event

The thread has connected and is waiting for binlog events to arrive. This can last for a long time if the master is idle. If the wait lasts for slave_read_timeout seconds, a timeout will occur. At that point, the thread will consider the connection to be broken and make an attempt to reconnect.

Queueing master event to the relay log

The thread has read an event and is copying it to the relay log so the SQL thread can process it.

Waiting to reconnect after a failed master event read

An error occurred while reading (due to disconnection). The thread is sleeping for master-connect-retry seconds before attempting to reconnect.

Reconnecting after a failed master event read

Then the thread tries to reconnect. When connection is established again, the state will become Waiting for master to send event.

Waiting for the slave SQL thread to free enough relay log space

You are using a non-zero relay_log_space_limit value, and the relay logs have grown so much that their combined size exceeds this value. The I/O thread is waiting until the SQL thread frees enough space by processing relay log contents so that it can delete some relay log files.

Waiting for slave mutex on exit

A very brief state that happens as the thread is stopping.

Here are the most common states you will see in the State column for the SQL thread of a slave server:

Reading event from the relay log

The thread has read an event from the relay log so that it can process it.

Has read all relay log; waiting for the slave I/O thread to update it

The thread has processed all events in the relay log files and is waiting for the I/O thread to write new events to the relay log.

Waiting for slave mutex on exit

A very brief state that happens as the thread is stopping.

The State column for the I/O thread may also show a query string. This indicates that the thread has read an event from the relay log, extracted the query from it and is executing the query.

Before MySQL 4.0.2, the slave I/O and SQL threads were combined as a single thread, and no relay log files were used. The advantage of using two threads is that it separates query reading and query execution into two independent tasks, so the task of reading queries is not slowed down if query execution is slow. For example, if the slave server has not been running for a while, its I/O thread can quickly fetch all the binlog contents from the master when the slave starts, even if the SQL thread lags far behind and may take hours to catch up. If the slave stops before the SQL thread has executed all the fetched queries, the I/O thread has at least fetched everything so that a safe copy of the queries is locally stored in the slave's relay logs for execution when next the slave starts. This allows the binlogs to be purged on the master, because it no longer need wait for the slave to fetch their contents.

By default, relay logs are named using filenames of the form `host_name-relay-bin.nnn', where host_name is the name of the slave server host, and nnn is a sequence number. Successive relay log files are created using successive sequence numbers, beginning with 001. The slave keeps track of relay logs currently in use in an index file. The default relay log index filename is `host_name-relay-bin.index'. By default these files are created in the slave's data directory. The default filenames may be overridden with the --relay-log and --relay-log-index server options.

Relay logs have the same format as binary logs, so they can be read with mysqlbinlog. A relay log is automatically deleted by the SQL thread as soon as it no longer needs it (that is, as soon as it has executed all its events). There is no command to delete relay logs, because the SQL thread takes care of doing so. However, from MySQL 4.0.14, FLUSH LOGS rotates relay logs, which will influence when the SQL thread deletes them.

A new relay log is created under the following conditions:

A slave replication server creates additional two small files in the data directory. These files are named `master.info' and `relay-log.info' by default. They contain information like that shown in the output of the SHOW SLAVE STATUS statement (see section 13.6.2 SQL Statements for Controlling Slave Servers for a description of this command). As disk files they survive slave's shutdown. The next time the slave starts up, it can read these files to know how far it has proceeded in reading binlogs from the master and in processing its own relay logs.

The `master.info' file is updated by the I/O thread. The correspondance between the lines in the file and the columns displayed by SHOW SLAVE STATUS is as follows:

Line Description
1 Master_Log_File
2 Read_Master_Log_Pos
3 Master_Host
4 Master_User
5 Password (not shown by SHOW SLAVE STATUS)
6 Master_Port
7 Connect_Retry

The `relay-log.info' file is updated by the SQL thread. The correspondance between the lines in the file and the columns displayed by SHOW SLAVE STATUS is as follows:

Line Description
1 Relay_Log_File
2 Relay_Log_Pos
3 Relay_Master_Log_File
4 Exec_Master_Log_Pos

When you back up your slave's data, you should back up these 2 small files as well, along with the relay log files. because they are needed to resume replication after you restore the slave's data. If you lose the relay logs but still have the `relay-log.info' file, you can check it to determine how far the SQL thread has executed in the master binlogs. Then you can use CHANGE MASTER TO with the MASTER_RELAY_LOG and MASTER_RELAY_POS options to tell the slave to re-read the binlogs from that point. This requires that the binlogs still exist on the master server.

If your slave is subject to replicating LOAD DATA INFILE statements, you should also backup the `SQL_LOAD-*' files that may exist in the directory that the slave uses for this purpose. The slave needs these files to resume replication of any interrupted LOAD DATA INFILE statements. The directory location is specified using the --slave-load-tmpdir option. Its default value if not specified is the value of the tmpdir variable.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated by rdg (Feb 25 2004) using texi2html