4.10.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 its binlogs. Then one thread (named Binlog_dump in SHOW PROCESSLIST on the master) is created on the master to send these binlogs. The I/O thread reads what Binlog_dump 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.

Here is how the three threads show up in SHOW PROCESSLIST:

| 76 | root | localhost | NULL | Binlog Dump |   42 | Slave: waiting for binlog update | NULL             |

|  7 | system user |           | NULL | Connect |    3 | Reading master update            | NULL             |
|  8 | system user |           | NULL | Connect |    3 | Slave: waiting for binlog update | NULL             |

Here thread 76 is on the master. Thread 7 is the I/O thread on the slave. Thread 8 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 4.10.8 Replication FAQ).

Before MySQL 4.0.2, the I/O and SQL threads were one. The advantage brought by the two separate threads is that it makes the reading job and the execution job independant, thus the reading job is not slowed down by the execution job. As soon as the slave starts, even if it has not been running for a while, the I/O thread can quickly fetch all the binlogs, while the SQL thread lags far behind and may take hours to catch. If the slave stops, though it has not executed everything yet, at least it has fetched everything, so binlogs can be purged on the master, as a safe copy is locally stored on the slave for future use.

Relay logs are by default named as the hostname followed by -relay-bin plus a numeric extension. A `-relay-bin.index' file contains the list of all relay logs currently in use. By default these files are in the slave's data directory. Relay logs have the same format than 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). The user has no command to delete relay logs as the SQL thread does the job. However, from MySQL 4.0.14, FLUSH LOGS rotates relay logs, which will influence deletion by the SQL thread. A new relay log is created when the I/O thread starts, or when the size of the current relay log exceeds max_relay_log_size (or if this variable is 0 or the slave is older than MySQL 4.0.14, when the size exceeds max_binlog_size), or when FLUSH LOGS is issued (from version 4.0.14).

Replication also creates two small files in the data directory: these files are the disk images of the output of SHOW SLAVE STATUS (see section 4.10.7 SQL Commands Related to Replication for a description of this command); but as disk images they survive slave's shutdown; this way at restart time the slave still knows his master and where the slave is in the master's binlogs, and where it is in its own relay logs.

• `master.info' is updated by the I/O thread. Here is a correspondance between the file's rows and the columns displayed by SHOW SLAVE STATUS:

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

• `relay-log.info' is updated by the SQL thread. Here is a correspondance between the file's rows and the columns displayed by SHOW SLAVE STATUS:

  Line#	Description
  1	Relay_Log_File
  2	Relay_Log_Pos
  3	Relay_Master_Log_File
  4	Exec_master_log_pos

User Comments

Add your own comment.