Chapter 6. Replication in MySQL

Table of Contents

6.1. Introduction to Replication
6.2. Replication Implementation Overview
6.3. Replication Implementation Details
6.3.6.3.1. Replication Master Thread States
6.3.6.3.2. Replication Slave I/O Thread States
6.3.6.3.3. Replication Slave SQL Thread States
6.3.6.3.4. Replication Relay and Status Files
6.4. How to Set Up Replication
6.5. Replication Compatibility Between MySQL Versions
6.6. Upgrading a Replication Setup
6.6.6.6.1. Upgrading Replication to 4.0 or 4.1
6.6.6.6.2. Upgrading Replication to 5.0
6.7. Replication Features and Known Problems
6.8. Replication Startup Options
6.9. Replication FAQ
6.10. Troubleshooting Replication
6.11. Reporting Replication Bugs

Replication capabilities allowing the databases on one MySQL server to be duplicated on another were introduced in MySQL 3.23.15. This chapter describes the various replication features provided by MySQL. It introduces replication concepts, shows how to set up replication servers, and serves as a reference to the available replication options. It also provides a list of frequently asked questions (with answers), and troubleshooting advice for solving problems.

For a description of the syntax of replication-related SQL statements, see the section called “Replication Statements”.

We suggest that you visit our Web site at http://www.mysql.com often and read updates to this chapter. Replication is constantly being improved, and we update the manual frequently with the most current information.

Introduction to Replication

MySQL 3.23.15 and up features support for one-way replication. One server acts as the master, while one or more other servers act as slaves. The master server writes updates to its binary log files, and maintains an index of the files to keep track of log rotation. These logs serve as a record of updates to be sent to slave servers. When a slave server connects to the master server, it informs the master of its last position within the logs since the last successfully propagated update. The slave catches up any updates that have occurred since then, and then blocks and waits for the master to notify it of new updates.

A slave server can also serve as a master if you want to set up chained replication servers.

Note that when you are using replication, all updates to the tables that are replicated should be performed on the master server. Otherwise, you must always be careful to avoid conflicts between updates that users make to tables on the master and updates that they make to tables on the slave.

One-way replication has benefits for robustness, speed, and system administration:

  • Robustness is increased with a master/slave setup. In the event of problems with the master, you can switch to the slave as a backup.

  • Better response time for clients can be achieved by splitting the load for processing client queries between the master and slave servers. SELECT queries may be sent to the slave to reduce the query processing load of the master. Statements that modify data should still be sent to the master so that the master and slave do not get out of sync. This load-balancing strategy is effective if non-updating queries dominate, but that is the normal case.

  • Another benefit of using replication is that you can perform backups using a slave server without disturbing the master. The master continues to process updates while the backup is being made. See the section called “Database Backups”.