MySQL Replication Modelmysql-tools.com/en/replication-in-mysql/35-replicating-mysql...MySQL...

Replicating MySQL DatabasesSaturday, 30 January 2010 10:38

Updates made to one database copy are automatically propagated to all the other replicas. Generally, one of the replicas is designated as the master where Updates are directed to themaster while read queries can be addressed to either the master or the slaves. If replicas other than master handle the updates, then keeping the replicas identical becomes more complex.

Here are some benefits of database replication:

- Availability: Any replica can be used as a "hot" backup where if the master database becomes unavailable, this replica can take over and can be designated as the master. Thefailures can be fixed and the failed replica can rejoin as a slave replica. - Backups: Replicas can be used as active backups and can be used to perform tediousoffline backups to file systems without locking up the primary instance. - Load Balancing: Replicas can serve split loads, also called load balancing, for heavilyused databases. Read queries can be distributed to the different replicas while updates arehandled by the master. This scenario works well when the number of read queries is fargreater than the number of update queries. - Proximity: Some replicas can be closer to users leading to improved response time. - Security: It is harder for malicious users to damage all the replicas provided they aresecured.

Support for replication is built into MySQL. There are no special add-ins or applications to install.

Note: Replication is a relatively new MySQL technology and is therefore a work in progressand evolving continuously. It is possible that implementation in your selected version of MySQL may vary from this lesson. Ensure to refer to the most current product documentation.

MySQL Replication Model

MySQL replication is based on a number of principles:

- In MySQL, replication is a one-way, asynchronous process, which means that changesare always propagated from the master server to the slave server, but never the other way around.

1 / 19


- The primary MySQL server acts as the Master server, and the servers that contain thecopied databases are considered the Slaveservers. - Data always moves from the master server to the slave server. As a result, onlydatabases on the master server should be updated. The updates are then propagated to the slave servers. - The master server must be configured with a user account that grants replicationprivileges to the slave server. The account allows the slave server to access the master serverin order to receive updates. - MySQL replication is based on the master database server recording all updates in abinary log. Binary logging must be enabled on the master server. The binary logs track allupdates to a database, and the logged updates are then used to synchronize the database onthe slave server. - To avoid conflicts, update queries are directed to the master while read queries can eithergo to the master or to the slaves. - The replicas connect to the master to read the binary log and then apply the updates tocatch up with the master. - The slave server uses replication coordinates to track updates. The coordinates arebased on the name of a binary log file on the master server and the position in that file. The fileand position represent where MySQL left off when the last update was performed on the slaveserver. The coordinates - along with other logon information - are stored in the master.info file on the slave host. - Each server that participates in the replication process must be assigned a uniquenumerical server ID. You assign the ID by specifying the server-id option in the [mysqld]section of the option file for each server. - A master server can replicate data to one or more slave servers. - To set up replication, the master server and slave server must begin with databases in a synchronized state. In other words, the databases to be replicated must be identical when replication is initiated. - No slave server can ever have two master servers. - It is generally best to have the master server and slave servers run the same version of MySQL. - There are two core types of replication format, Statement Based Replication (SBR), which replicates entire SQL statements, and Row Based Replication (RBR), which replicates only thechanged rows. You may also use a third variety, Mixed Based Replication (MBR), which is thedefault mode within MySQL 5.1.14 and later. Further details can be found in MySQL documentation.

We will look at two common configurations for replication. One is used primarily for database

2 / 19


availability and the other for load balancing. Please refer the MySQL documentation for moredetails.

Availability

In this configuration, one database is the master while the other is designated as a slave. Only updates to the master are logged.

It is possible to have more than one slave, depending on load and other needs.

Load Balancing

The following configuration provides a load balancing scenario, where Read queries aredirected to either the master or any of the replicas while update queries are directed only to themaster:

Setting up Replication

Here are the basic steps to set up replication. The gruesome details will follow in a subsequent

3 / 19


section:

- Enable binary logging on the master server. - Make a backup of the master database. - Start a new binary log immediately after making the backup. - Set up a user account on the master server that grants replication privileges to the slaveserver. The account allows the slave server to access the master server in order to receiveupdates. - Assign a unique numerical server ID to each server that participates in the replicationprocess. - Block all updates to the master. - Create a Slave instance. - Load the backup of the master database into the slave - Apply the updates from the binary log to the slave to sync up with the master. - Get both the master and slave running.

Replication Files on the Slave

When replication is implemented, the slave server maintains a set of files to support the replication. MySQL automatically creates the three types of files on the slave server:

- <host>-relay-bin.<extension>:

Contains the statements to be used to synchronize the replicated database with the databaseon the master server. The relay log files receive their data from the binary log files on themaster server. Similar to binary logs, the filename extension is a number, starting with 000001,that is incremented whenever a relay log file is added.

- master.info:

Contains connection information such as the master server hostname, user account and itspassword. Also maintains information about the last binary log file on the master server to beaccessed and the position in that file.

- relay-log.info:

Contains information about the relay log files and tracks the last position in those files in whichthe replicated database was updated.

4 / 19


The replication log files are created automatically when you implement replication.

Updates in the master binary log files are copied to the relay log files, which reside on the slave server. The content of the relay log files is then used to update the replicated databaseon the slave server.

MySQL deletes the relay log file (<host>-relay-bin.<prefix number>) after the statements in thefile have been executed and the replicated database has been updated.

The master.info and relay-log.info files are updated as needed to support the replicationprocess and to keep the copied databases updated. If you back up a slave server, you shouldalso back up the relay log files, the master.info file, and the relay- log.infofile so that you can restore the slave server if necessary.

Replication Chaining

A slave server can be made a master server to another slave server in order to create a replication chain.

For example, <Primary-Server> can be configured as a master server that replicates data to <Slave-Server>, the slave server. <Slave-Server>can also be configured as a master server that replicates data to <Slave-2-Server>. As a result, <Primary-Server>is replicated to <Slave-Server>, and <Slave- Server>is replicated to <Slave-2-Server>

5 / 19


.

Alternately, you can change your mind and replicate <Primary-Server> directly to <Slave-2-Server> so that <Slave- Server>and <Slave-2- Server>are slave servers to <Primary- Server>.

Implementing Replication - Details Set up Replication User

To allow a master server to replicate data to a slave server, you must set up a user account onthe master server. The slave server then uses that account to establish a connection to the master server:

Syntax GRANT REPLICATION SLAVE ON *.*TO '<slave account>'@'<slave host>'IDENTIFIED BY '<password>';

The REPLICATION SLAVE privilege at the global level is specific to the process of replicationand allows all changes to a database to be replicated to the copy of the database on the slaveserver. The TO clause defines the username on the account andhost from which that account can connect. This is the host where the slave server resides. The

IDENTIFIED BY clause then identifies the passwordthat should be used when the slave server logs on to the master server.

Code Sample: Replication/Demos/Grant-Slave-User.sql GRANT REPLICATION SLAVE ON *.*TO 'slaveuser'@'localhost'IDENTIFIED BY 'slave'; Making Initial Backup

Make a backup of the databases that you want to replicate. Use the --master- data option in themysqldump

command. The --master-dataoption adds a

6 / 19


CHANGE MASTERstatement similar to the following to your backup file:

CHANGE MASTER TO MASTER_LOG_FILE='mastsrv-bin.000201',MASTER_LOG_POS=64;

The CHANGE MASTER statement identifies the binary log file and the position in that file atthe time that the backup file is created. You use this information later when you set up replication on the slave server. This information allows you to synchronize the slave server with the master server.

Configuration Changes on Master - Shut down the master server. - Modify the [mysqld] group in the option file on the master server to specify a server ID forthe master server. The master server and any slave servers must each be assigned a uniquenumerical ID. - In addition, if you don't want to replicate a specific database, such as the mysql or testdatabases, you can add a binlog-ignore-db option for each database to prevent changesto that database from being logged to the binary file. As a result, changes to those tablesaren't replicated. When you're finished editing the option file, the [mysqld]section should include options similar to the following: Code Sample: Replication/Demos/bin-log-fragment.txt [mysqld]

log-binbinlog-db=sakilabinlog-ignore-db=mysqlbinlog-ignore-db=testserver-id=masterserver;

The log-bin option specifies that binary logging should be enabled. The two binlog-ignore-db options specify that changes to the mysql and test databases should not be logged to the binaryfiles. The server-idoption specifies the numbered ID for the master server.

Note:If you use an existing option file, a server-id may already be present.If multiple optionsare specified and the numerical IDs are different, replication might not work.

7 / 19


- Restart the master server.

Configuration Changes on the Slave - Shut down the slave server. - Modify the option file on the slave server so that the [mysqld] section includes thefollowing settings: server-id=<slave server id> - Make certain that this server ID is different from the master server ID and different fromany other slave server IDs. Also be sure that this is the only server-id option defined on the slave server. - Restart the slave server.

Restore Backup on Slave

Use the backup file created on Master to load the databases into the slave server.

Set up Connection to Master

Specify the settings that will be used for the slave server to connect to the master server anddetermine which binary log file to access. Launch the mysql client utility on the slave server,and then execute the following CHANGE MASTER statement:

Syntax CHANGE MASTER TO MASTER_HOST='<master host>', MASTER_USER='<user account>', MASTER_PASSWORD='<password>', MASTER_LOG_FILE='<log file>', MASTER_LOG_POS=<position>;

The slave server adds this information to the master.info file, which is used when connecting tothe master server. (The CHANGEMASTERstatement is discussed in more detail later in this section.)

Start Replication on Slave

The final step that you must take is to start the replication process on the slave server. To doso, execute the following SQL statement on the slave server:

8 / 19


START SLAVE;

The statement initiates the threads that connect from the slave server to the master server.

Verifying Replication

Once replication is set up, update a table on the master server and then confirm whether that change has been replicated to the slave server. If the change is reflected on the slave server, replication has been properly set up. Once replication is implemented, you might find that youneed to view replication settings or make a change. Fortunately, MySQL allows you toadminister the replication environment.

Managing Replication

To support administering replication, MySQL provides a number of SQL statements that allowyou to view information about the replication environment or take a specific action. MySQLsupports statements for both the master server and the slave server.

Managing the Master Server

MySQL provides several statements to to manage replication on the master server.

Using the RESET MASTER Statement

When you're setting up replication, you might find that you first want to clean up the binary logson your master server. Once you have backed up the log files and the index file, you can delete these files and start from scratch. The easiest way to do this is to issue the following statement:

RESET MASTER;

The RESET MASTER statement deletes all your binary log files, removes them from your binary index file, and starts logging with a new log file.

Using the SHOW MASTER STATUS Statement

We created a backup file of the databases that you want to replicate. Indeed, the step instructsyou to use the --master-data option in your mysqldump command. The command adds a CHANGE MASTER

9 / 19


statement to your backup file that contains the binary log filename and the position in the filethat you should use as a starting point when implementing replication on a slave server.

Using the --master-data option in the mysqldump command is a handy way of preserving thefilename and position when you go to implement replication on the server. You merelyreference the backup file and retrieve that information from there. You can determine thebinary log filename and position using the following statement:

Code Sample: Replication/Demos/Show-Master-Status.sql SHOW MASTER STATUS;

When you execute the statement, you should receive results similar to the following partialresult set:

+--------------------+----------+--------------+-----------------| File | Position | Binlog_Do_DB | Binlog_Ignore_DB+--------------------+----------+--------------+-----------------| mastsrv-bin.000041 | 134 | sakila | mysql,test +--------------------+----------+--------------+-----------------1 row in set (0.00 sec)

The results include:

- A binary log filename (mastsrv-bin.000041) - A position in the binary log (134) - The Binlog_Do_DB column lists any databases that are specifically logged to the binaryfiles. Currently, only changes to sakila are being explicitly logged. - The Binlog_Ignore_DB column shows mysql and test databases where changes to those two databases are not logged.

The SHOW MASTER STATUS statement provides a quick method for discovering the current position in a log file. If you are using this information as part of setting up replication, you mustbe sure that it is applied exactly to when you backed up the databases.

For example, if an update had been issued against the database in between when you createdthe backup file and when you checked the master status, the master status information would

10 / 19


no longer be accurate.

If you cannot guarantee the accuracy of the master status information, you should simply addthe --master-data option to your mysqldump command.

Including/Ignoring Databases

You can log changes to a specific database by adding the binlog-do- db option to the [mysqld]section of your option file.

You can prevent changes to a specific database from being logged by adding the binlog-ignore- db optionto the [mysqld]section of your option file. If changes to a database are not logged to the binary log files, thatdatabase cannot be replicated.

Using the SHOW SLAVE HOSTS Statement

To find which slave servers are connected to your master server currently, execute thefollowing statement:

Code Sample: Replication/Demos/Show-Slave-Hosts.sql SHOW SLAVE HOSTS;

The SHOW SLAVE HOSTS statement should return results similar to the following:

+-----------+----------+------+-------------------+-----------+| Server_id | Host | Port | Rpl_recovery_rank | Master_id |+-----------+----------+------+-------------------+-----------+| 3 | slavsrv | 3306 | 0 | 1 |+-----------+----------+------+-------------------+-----------+1 row in set (0.00 sec)

The results should include a row for each slave that is connected to the master. The resultsprovides:

11 / 19


- Server ID of the slave (3) - Name of the slave host (slavsrv) - Port used to connect to the master (3306) - replication recovery rank (0) - not presently used - Server ID of the master server (1).

Please note that:

- By default, a slave server is not listed in the results returned by the SHOW SLAVE HOSTS statement. Toshow a slave server in the results above, modify the option file on the slave server to includethe --report-host=<host>option to the [mysqld]section, where <host;> the name of the slave host (slavsrv). - You can also use the SHOW PROCESSLIST statement to view a list of the threads thatare currently running. - The replication recovery rank may be used in future to rank master servers where if aslave server loses its master, it can select a new master based on the master ranks.

Managing the Slave Server

MySQL also provides several statements to manage the replication environment on a slaveserver.

Using the CHANGE MASTER Statement

As seen before, the CHANGE MASTER statement provides the parameters that are used bythe master.info file on the slave server. The followingsyntax shows how to define a CHANGE MASTERstatement:

CHANGE MASTER TO <master option> [<master option>...] Primary Change Masteroptions specified on Slave

Option syntax Description

12 / 19


MASTER_HOST='<master host>' The name of the master server MASTER_USER='<user account>' The name of the user account set up for the slave server MASTER_PASSWORD='<password>' The password for the user account set up for the slave server MASTER_PORT=<port number> The port number used to connect to the MySQL server on the master server MASTER_CONNECT_RETRY=<count> The number of times to try to reconnect to the master server if a connection cannot be established initially MASTER_LOG_FILE='<log file>' The name of the binary log file on the master server that the slave server should begin reading from when implementing replication on the slave server MASTER_LOG_POS=<position> The position in the binary log file that determines where to start searching the log files in order to synchronize the slave server with the master server RELAY_LOG_FILE=<log file> The name of the relay log file on the slave server that the slave server should begin reading from when implementing replication RELAY_LOG_POS=<position> The position in the relay log file that determines where to start searching the log files in order to implement replication

Some key points to note:

- The CHANGE MASTER statement is used when initiating replication on a slave server - It may be used again if connection information changes after replication has started. - You don't have to specify all options. If you change the password for the user account that connects to the master server, simply specify only the MASTER_PASSWORD='<password>' option. - If you specify either one of the MASTER_HOST='<master host>' and the MASTER_PORT=<port number>options, you must also specify the MASTER_LOG_FILE='<log file>'option and the MASTER_LOG_POS=<position>option. - If you specify the MASTER_LOG_FILE='<log file>' or the MASTER_LOG_POS=<position> option, you cannot specify the

RELAY_LOG_FILE=<log file> or RELAY_LOG_POS=<position> option.

For example:

Code Sample: Replication/Demos/Change-Master.sql CHANGE MASTER TO MASTER_HOST='primserver', MASTER_USER='slaveuser', MASTER_PASSWORD='amslave', MASTER_LOG_FILE='primserver-bin.00917', MASTER_LOG_POS=85; Code Explanation

13 / 19


In this statement, the master host is primserver, the account used to log on to the host is slaveuser, and the password for that account is amslave. In addition, the master log binary file is primserver-bin.00917, and the position in that log is 85.

Executing this statement will add the information to the master.info file.

Using the RESET SLAVE Statement

If you want to start over with setting up replication on the slave server, you can reset the slaveby using the following statement:

RESET SLAVE;

The statement deletes all the relay log files as well as the master.info and relay- log.info files.The statement then re-creates all the necessary replication files, providing you with a cleanstart.

Note: The master.info file will no longer contain the values necessary to connect to the masterserver, requiring an execution of the CHANGE MASTER statement.

SHOW SLAVE STATUS Statement

The SHOW SLAVE STATUS statement provides status information about the connection to the master server, the binary log file and relay log file, and the positions in the log files:

SHOW SLAVE STATUS; +----------------------------------+-------------+------------| Slave_IO_State | Master_Host | Master_User+----------------------------------+-------------+------------| Waiting for master to send event | primserver | slaveuser +----------------------------------+-------------+------------1 row in set (0.00 sec)

The results shown here represent only a small part of the information shown for the SHOWSLAVE STATUSstatement. For a complete list of the information returned by the statement, refer the MySQLproduct documentation.

14 / 19


START SLAVE Statement

On a stopped the slave server or for a first-time slave, start the replication process on the slave server by using the following statement:

START SLAVE;

The statement starts the connections to the master server that are necessary for replication to work. A slave server will use two connections to the master.

- I/O connection: Accesses data in the binary log files on the master server and copiesthat data to the relay logs. - SQL connection: Reads the relay logs and executes the statements against thedatabases on the slave server.

STOP SLAVE Statement

To stop replication on the slave server, use the following statement:

STOP SLAVE;

The statement stops both the connections above and stops the replication of databaseschanges. The replication files are preserved so replication process can be restarted with the START SLAVEstatement.

Replication Configuration Options

The Table below lists the common replication-related configuration options:

Common Replication Configuration Options

Option

Description

master-connect-retry

15 / 19


=<number>

Number of seconds the slave thread will sleep before retrying to connect to the master in case the master goes down or the connection is lost

master-host=<name>

Master hostname or IP address for replication (required for slave to run); can also exist in master.info file

master-password

=<password>

Slave thread will use this password when connecting to the master

master-port=<number>

Port on master for slave connections

master-retry-count

=<number>

Number of tries the slave will make to connect to the master before giving up

master-ssl

Enable the slave to connect to the master using SSL

master-user=<name>

Slave thread will use this name when connecting to the master

max_relay_log_size

16 / 19


=<number>

Size at which relay log is rotated (minimum is 4096); set to 0 to have relay log rotated with max_binlog_size

relay-log=<file>

File location and name where relay logs are stored

replicate-do-db=<name>

Tells slave to replicate a specific database; use directive multiple times to specify multiple databases

replicate-do-table

=<name>

Tells slave to replicate only the named table; use directive multiple times to specify more than one table

replicate-ignore-db

=<name>

Tells slave to ignore this database; use directive multiple times to specify multiple databases

replicate-ignore-table

=<name>

Tells slave to ignore this table; use directive multiple times to specify multiple tables

relay-log-info-file=<file>

17 / 19


File that maintains the position of the replication thread in the relay logs; default is in data directory

replicate-wild-do-table

=<name>

Slave replicates tables matching the wildcard pattern; use directive multiple times to specify multiple databases

replicate-wild-ignore

-table=<name>

Slave ignores tables matching the wildcard pattern; use directive multiple times to specify multiple wildcard patterns

server-id=<number>

Unique identifier for server when a part of replication system

slave-load-tmpdir

=<dir>

Location for slave to store temporary files when replicating a LOAD DATA INFILE command

slave-skip-errors

Slave continues replication when an error is returned from processing a query

skip-slave-start

Don't automatically start slave

18 / 19


Replication in MySQL Conclusion

This lesson covered the replication operations in MySQL.

-

Replicating databases on a MySQL server

-

Managing the master and slave servers used in replication

In addition to creating backup files, you can set up replication in order to maintain at least onesynchronized copy of your database. In this case, you would set up a slave server that can beused to create backup files. This way, applications and users accessing the master server arenot competing for resources also being used to back up the data. This approach can beparticularly useful when developing Web-based applications that must be available around theclock and that can experience large numbers of concurrent users.

To continue to learn MySQL go to the top of this page and click on the next lesson in thisMySQL Tutorial's Table of Contents.

19 / 19

MySQL Replication Modelmysql-tools.com/en/replication-in-mysql/35-replicating-mysql...MySQL...

Documents

Transcript of MySQL Replication Modelmysql-tools.com/en/replication-in-mysql/35-replicating-mysql...MySQL...