Before this how to set up replication, take a quickly look at the steps that MySQL goes through to maintain a replicated server. The process is different depending on the version of MySQL. For purposes of this article, my comments will be for version 4.0 or higher, since most systems now are using the later versions.

When replication is running, basically, as SQL statements are executed on the master server, MySQL records them in a binary log (bin.log) along with a log position identification number. The slave server in turn, through an IO thread, regularly and very often reads the master’s binary log for any changes. If it finds a change, it copies the new statements to its relay log (relay.log). It then records the new position identification number in a file (master.info) on the slave server. The slave then goes back to checking the master binary log, using the same IO thread. When the slave server detects a change to its relay log, through an SQL thread the slave executes the new SQL statement recorded in the relay log. As a safeguard, the slave also queries the master server through the SQL thread to compare its data with the master’s data. If the comparison shows inconsistency, the replication process is stopped and an error message is recorded in the slave’s error log (error.log). If the results of the query match, the new log position identification number is recorded in a file on the slave (relay-log.info) and the slave waits for another change to the relay log file.

This process may seem involved and complicated at first glance, but it all occurs quickly, it isn’t a significant drain on the master server, and it ensures reliable replication. Also, it’s surprisingly easy to set up. It only requires a few lines of options to be added to the configuration file (i.e., my.cnf) on the master and slave servers.

How to Set Up Replication

There are a number of different methods for setting up replication, and the exact method that you use will depend on how you are setting up replication, and whether you already have data within your master database.

I. Creating a User for Replication

Each Slave must connect to the Master using a standard username and password. It’s best not to use an existing account for security reasons, for the username and password will be stored in plain text within the master.info file. To do this, enter an SQL statement like the following on the master server, logged in as root or a user that has GRANT OPTION privileges:

mysql> GRANT REPLICATION SLAVE ON *.*
       -> TO 'replic'@'192.168.0.6' IDENTIFIED BY 'passwdhere';

In this SQL statement, the user account replic is granted only what’s needed for replication. The user name can be almost anything. The IP address(or host name) 192.168.0.6 is given in quotes which is allowed to connect for replication. You should enter this same statement on the slave server with the same user name and password, but with the master’s host name or IP address. This way, if the master fails and will be down for a while, you could redirect users to the slave with DNS or by some other method. When the master is back up, you can then use replication to get it up to date by temporarily making it a slave to the former slave server. Incidentally, if you upgraded MySQL to version 4.0 recently, but didn’t upgrade your mysql database, the GRANT statement above won’t work because these privileges didn’t exist in the earlier versions.

II. Configuring Replication Master

For replication to work you must enable binary logging on the master, for it is the binary log that is used to exchange data between the master and slaves.

Each server within a replication group must have a unique server-id. The server-id is used to identify individual servers within the group. You will need to add the following options to the configuration file my.cnf within the [mysqld] section. For example, to enable binary logging, using a log filename prefix of mysql-bin, and setting a server ID of 1:

[mysqld]
log-bin=mysql-bin
server-id=1

Ensure that the skip-networking option has not been enabled on your replication master. If networking has been disabled, then your slave will not able to communicate with the master and replication will fail.

III. Configuring Replication Slave

The only option you must configure on the slave is to set the unique server ID. Ensure that the slave server has the followling effective option:

[mysqld]
server-id=2

If you are setting up multiple slaves, each one must have a unique server-id value that differs from that of the master and from each of the other slaves. You do not have to enable binary logging on the slave for replication to be enabled. However, if you enable binary logging on the slave then you can use the binary log for data backups and crash recovery on the slave, and also use the slave as part of a more complex replication topology.

IV. Obtaining the Master Replication Information

To configure replication on the slave you must determine the masters current point within the master binary log. You will need this information so that when the slave starts the replication process, it is able to start processing events from the binary log at the correct point.

If you have existing data on your master that you want to synchronize on your slaves before starting the replication process, then you must stop processing statements on the master, obtain the current position, and then dump the data, before allowing the master to continue executing statements. If you do not stop the execution of statements then the data dump, the master status information that you use will not match and you will end up with inconsistent or corrupted databases on the slaves.

Start the command line client and flush all tables and block write statements by executing the FLUSH TABLES WITH READ LOCK statement:

mysql> FLUSH TABLES WITH READ LOCK;

Use the SHOW MASTER STATUS statement to determine the current binary log name and offset on the master:

mysql > SHOW MASTER STATUS;
+-----------------+----------+-----------------+---------------------+
| File                | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-----------------+----------+-----------------+---------------------+
|mysql-bin.0006| 98         |                      |                          |
+-----------------+----------+-----------------+---------------------+

The File column shows the name of the log and Position shows the offset within the file. In this example, the binary log file is mysql-bin.006 and the offset is 98. Record these values. You need them later when you are setting up the slave.

Keep the databases tables with read lock and follow the next step.

V. Creating a Data Snapshot of Master

There are several different ways to take a databases snapshot. From my experience, I prefer mysqlhotcopy(only for backing up MyISAM tables). For example, on master:

shell> mysqlhotcopy --allowold --noindices -u root -p passwdhere database-names /path-to-destdir

When choosing databases to include in the copy, remember that you will need to filter out databases on each slave that you do not want to include in the replication process. Once you have created the archive or copy of the database, you will need to copy the files to each slave before starting the slave replication process. Now you could free the read lock on master:

mysql> UNLOCK TABLES;

VI. Making Replication Process Running

Importing the databases into slave, then starting the slave, skipping replication by using the –skip-slave option.

To set up the slave to communicate with the master for replication, you must tell the slave the necessary connection information. To do this, execute the following statement on the slave, replacing the option values with the actual values relevant to your system:

mysql> CHANGE MASTER TO
       -> MASTER_HOST='master_host_name',
       -> MASTER_USER='replication_user_name',
       -> MASTER_PASSWORD='replication_password',
       -> MASTER_LOG_FILE='recorded_log_file_name',
       -> MASTER_LOG_POS=recorded_log_position;

After that, start the replication threads:

mysql> START SLAVE;

After you have performed this procedure, the slave should connect to the master and catch up on any updates that have occurred since the snapshot was taken.

There are more replication startup options and variables, check the manual for details.

VII. Checking Replication Status

It’s required that you ensure that replication is taking place and that there have been no errors between the slave and the master. One command for this is SHOW SLAVE STATUS which you must execute on each slave:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
                  Slave_IO_State: Waiting for master to send event
                      Master_Host: 192.168.0.16
                     Master_User: replic
                      Master_Port: 3306
                  Connect_Retry: 60
                 Master_Log_File: mysql-bin.000024
         Read_Master_Log_Pos: 4279
                   Relay_Log_File: slave1-relay-bin.000056
                   Relay_Log_Pos: 950
         Relay_Master_Log_File: mysql-bin.000024
               Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
                 Replicate_Do_DB:
            Replicate_Ignore_DB:
             Replicate_Do_Table:
       Replicate_Ignore_Table:
     Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                           Last_Errno: 0
                            Last_Error:
                       Skip_Counter: 0
           Exec_Master_Log_Pos: 4279
                 Relay_Log_Space: 4418
                     Until_Condition: None
                      Until_Log_File:
                      Until_Log_Pos: 0
            Master_SSL_Allowed: No
            Master_SSL_CA_File:
           Master_SSL_CA_Path:
                 Master_SSL_Cert:
              Master_SSL_Cipher:
                  Master_SSL_Key:
       Seconds_Behind_Master: 0
1 row in set (0.01 sec)

The key fields from the status report to examine are:

Slave_IO_State — indicates the current status of the slave.
Slave_IO_Running — shows whether the IO thread for the reading the master’s binary log is running.
Slave_SQL_Running — shows whether the SQL thread for the executing events in the relay log is running.
Last_Error — shows the last error registered when processing the relay log. Ideally this should be blank, indicating no errors.
Seconds_Behind_Master — shows the number of seconds that the slave SQL thread is behind processing the master binary log.
A high number (or an increasing one) can indicate that the slave is unable to cope with the large number of queries from the master.

On the master, you can check the status of slaves by examining the list of running processes. Slaves execute the Binlog Dump command:

*************************** 1. row ***************************
     Id: 112
   User: syn
   Host: 192.168.0.16:56644
     db: NULL
Command: Binlog Dump
   Time: 71268
  State: Has sent all binlog to slave; waiting for binlog to be updated
   Info: NULL
*************************** 2. row ***************************
     Id: 112935
   User: root
   Host: localhost
     db: NULL
Command: Query
   Time: 0
  State: NULL
   Info: SHOW PROCESSLIST
2 rows in set (0.00 sec)