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

Transcription

1 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 the master 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. The failures 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 tedious offline backups to file systems without locking up the primary instance. - Load Balancing: Replicas can serve split loads, also called load balancing, for heavily used databases. Read queries can be distributed to the different replicas while updates are handled by the master. This scenario works well when the number of read queries is far greater 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 are secured. 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 progress and 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 changes are always propagated from the master server to the slave server, but never the other way around. 1 / 19

2 - The primary MySQL server acts as the Master server, and the servers that contain the copied databases are considered the Slav e servers. - Data always moves from the master server to the slave server. As a result, only databases 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 replication privileges to the slave server. The account allows the slave server to access the master server in order to receive updates. - MySQL replication is based on the master database server recording all updates in a binary log. Binary logging must be enabled on the master server. The binary logs track all updates to a database, and the logged updates are then used to synchronize the database on the slave server. - To avoid conflicts, update queries are directed to the master while read queries can either go to the master or to the slaves. - The replicas connect to the master to read the binary log and then apply the updates to catch up with the master. - The slave server uses replication coordinates to track updates. The coordinates are based on the name of a binary log file on the master server and the position in that file. The file and position represent where MySQL left off when the last update was performed on the slave server. The coordinates - along with other logon information - are stored in the master.inf o file on the slave host. - Each server that participates in the replication process must be assigned a unique numerical 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 the changed rows. You may also use a third variety, Mixed Based Replication (MBR), which is the default mode within MySQL 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

3 availability and the other for load balancing. Please refer the MySQL documentation for more details. 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 are directed to either the master or any of the replicas while update queries are directed only to the master: Setting up Replication Here are the basic steps to set up replication. The gruesome details will follow in a subsequent 3 / 19

4 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 slave server. The account allows the slave server to access the master server in order to receive updates. - Assign a unique numerical server ID to each server that participates in the replication process. - 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 database on the master server. The relay log files receive their data from the binary log files on the master server. Similar to binary logs, the filename extension is a number, starting with , that is incremented whenever a relay log file is added. - master.info: Contains connection information such as the master server hostname, user account and its password. Also maintains information about the last binary log file on the master server to be accessed 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 which the replicated database was updated. 4 / 19

5 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 database on the slave server. MySQL deletes the relay log file (<host>-relay-bin.<prefix number>) after the statements in the file 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 replication process and to keep the copied databases updated. If you back up a slave server, you should also back up the relay log files, the master.info file, and the r elay- log.info file 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

6 . Alternately, you can change your mind and replicate <Primary-Server> directly to <Slave-2-Ser ver> 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 on the 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 replication and allows all changes to a database to be replicated to the copy of the database on the slave server. The TO clause defines the username on the account and host from which that account can connect. This is the host where the slave server resides. The IDENTIFIED BY clause then identifies the password that 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 the mysqldump command. The --master-data option adds a 6 / 19

7 CHANGE MASTER statement similar to the following to your backup file: CHANGE MASTER TO MASTER_LOG_FILE='mastsrv-bin ', MASTER_LOG_POS=64; The CHANGE MASTER statement identifies the binary log file and the position in that file at the 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 for the master server. The master server and any slave servers must each be assigned a unique numerical ID. - In addition, if you don't want to replicate a specific database, such as the mysql or test databases, you can add a binlog-ignore-db option for each database to prevent changes to that database from being logged to the binary file. As a result, changes to those tables aren'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-bin binlog-db=sakila binlog-ignore-db=mysql binlog-ignore-db=test server-id=masterserver; The log-bin option specifies that binary logging should be enabled. The two binlog-ignore-db o ptions specify that changes to the mysql and test databases should not be logged to the binary files. The server-id option 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 options are specified and the numerical IDs are different, replication might not work. 7 / 19

8 - 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 the following settings: server-id=<slave server id> - Make certain that this server ID is different from the master server ID and different from any 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 and determine 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 to the master server. (The CHANGE MASTER statement 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 do so, execute the following SQL statement on the slave server: 8 / 19

9 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 you need to view replication settings or make a change. Fortunately, MySQL allows you to administer the replication environment. Managing Replication To support administering replication, MySQL provides a number of SQL statements that allow you to view information about the replication environment or take a specific action. MySQL supports 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 logs on 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 instructs you to use the --master-data option in your mysqldump command. The command adds a CHA NGE MASTER 9 / 19

10 statement to your backup file that contains the binary log filename and the position in the file that 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 the filename and position when you go to implement replication on the server. You merely reference the backup file and retrieve that information from there. You can determine the binary 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 partial result set: File Position Binlog_Do_DB Binlog_Ignore_DB mastsrv-bin sakila mysql,test row in set (0.00 sec) The results include: - A binary log filename (mastsrv-bin ) - A position in the binary log (134) - The Binlog_Do_DB column lists any databases that are specifically logged to the binary files. 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 must be 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 created the backup file and when you checked the master status, the master status information would 10 / 19

11 no longer be accurate. If you cannot guarantee the accuracy of the master status information, you should simply add the --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-ignor e- db option to the [mysqld] section of your option file. If changes to a database are not logged to the binary log files, that database cannot be replicated. Using the SHOW SLAVE HOSTS Statement To find which slave servers are connected to your master server currently, execute the following 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 slavsrv row in set (0.00 sec) The results should include a row for each slave that is connected to the master. The results provides: 11 / 19

12 - 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. To show a slave server in the results above, modify the option file on the slave server to include the --report-ho st=<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 that are currently running. - The replication recovery rank may be used in future to rank master servers where if a slave 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 slave server. Using the CHANGE MASTER Statement As seen before, the CHANGE MASTER statement provides the parameters that are used by the master.info file on the slave server. The following syntax shows how to define a CHANG E MASTER statement: CHANGE MASTER TO <master option> [<master option>...] options specified on Slave Primary Change Master Option sy 12 / 19

13 MASTER_HOST='<master The host>' 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 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 serve MASTER_CONNECT_RETRY=<count> The number of times to try to reconnect to the master server if a connection MASTER_LOG_FILE='<log The file>' name of the binary log file on the master server that the slave server sh MASTER_LOG_POS=<position> The position in the binary log file that determines where to start searching th RELAY_LOG_FILE=<log The file> name of the relay log file on the slave server that the slave server shou RELAY_LOG_POS=<position> The position in the relay log file that determines where to start searching the 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='<pas sword>' option. - If you specify either one of the MASTER_HOST='<master host>' and the MASTER_POR T=<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

14 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 slave by 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 clean start. Note: The master.info file will no longer contain the values necessary to connect to the master server, 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 row in set (0.00 sec) The results shown here represent only a small part of the information shown for the SHOW SLAVE STATUS statement. For a complete list of the information returned by the statement, refer the MySQL product documentation. 14 / 19

15 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 copies that data to the relay logs. - SQL connection: Reads the relay logs and executes the statements against the databases 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 databases changes. The replication files are preserved so replication process can be restarted with the S TART SLAVE statement. Replication Configuration Options The Table below lists the common replication-related configuration options: Common Replication Configuration Options Option Description master-connect-retry 15 / 19

16 =<number> Number of seconds the slave thread will sleep before retrying to connect to the master in case the mast master-host=<name> Master hostname or IP address master.info for replication (required file for slave to run); can also exist in 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

17 =<number> Size at which relay log is max_binlog_size rotated (minimum is 4096); set to 0 to have relay log rotated with 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

18 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 dat replicate-wild-ignore -table=<name> Slave ignores tables matching the wildcard pattern; use directive multiple times to specify multiple wildc server-id=<number> Unique identifier for server when a part of replication system slave-load-tmpdir =<dir> Location for slave to store LOAD temporary DATA files INFILE when replicating commanda 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

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 one synchronized copy of your database. In this case, you would set up a slave server that can be used to create backup files. This way, applications and users accessing the master server are not competing for resources also being used to back up the data. This approach can be particularly useful when developing Web-based applications that must be available around the clock 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 this MySQL Tutorial's Table of Contents. 19 / 19