 |
» |
|
|
 |
|  |  |
The MySQL replication feature allows the database on one server
to be precisely duplicated on one or more other servers. This capability
is enabled through an asynchronous master/slave relationship. Each
slave server starts out with an exact copy of the data held on the
master server. The master server publishes a binary log to the slave
servers of all changes made to the data in the database. The slave
servers read changes to the binary logs that have occurred since the
last successful update. In this way, the slave servers are able to update their copies
of the database. All changes to the database must be made to the master
server, but clients may access data for reading through either the
master server or any slave server. Figure 4 depicts
the replication configuration. This replication scheme offers two key advantages. First, backing
up the database is easier and safer. A slave server can be taken off
line, and all its data can be backed up without impacting the overall
operation of the live database. During backup, the master server and
any other slave servers continue responding to queries uninterrupted.
When the backup is complete, the backed-up slave server is brought
up to date with any changes that have occurred during the backup,
and then the slave server is returned to normal operation. The second advantage of replication is improved read performance.
You can scale out the MySQL server in response to higher loads using
this type of one-way replication. Splitting the load for processing
client queries between the master server and slave servers provides
better response time for clients. The select queries
that read data are sent to the slave server to reduce the query processing
load of the master server. Commands that modify data are still sent
to the master server to ensure that the master server and slave servers
remain synchronized. This load-balancing strategy is effective in
situations where read-only queries dominate. Additional slave servers
can be added as needed to meet an increase in demand. Configuring the Master Server and Slave Servers |  |
Download the appropriate version of the MySQL server and
client packages, as displayed in Table 1. Install the packages on the systems you use as the master
server and slave server. For the example in this section, assume the
host name of the master server is master.test and
the host name of the slave server is slave.test. Perform the basic configuration steps, as described in “Installing and Configuring the MySQL Database ”,
so the MySQL server can be started correctly on both machines.
Configuring the Master ServerEdit the [mysqld] section of the /etc/my.cnf file on the master server to include a log-bin option. Also include a server-id=master_id option in this section, where master_id must be a positive
integer value from 1 to 232 -1. For example: [mysqld] log-bin=mysql-bin server-id=1  |  |  |  |  | NOTE: The server-id value configured in this step
must be unique to each server in the replication configuration. No
two slave servers or the master server may have the same server-id value. |  |  |  |  |
Restart the MySQL server on the master server, and make
sure no errors occurred by entering the following command: # /etc/init.d/mysql
restart Run the following command in the MySQL client to verify
that the master server is running correctly, and to gather the necessary
information for configuring the slave servers: mysql> show master status; The sample output looks as follows: +-----------------------+-----------+-------------------+------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-----------------------+-----------+-------------------+------------------------+
| mysql-bin.000001 | 1678 | | |
+-----------------------+-----------+-------------------+------------------------+
1 row in set (0.00 sec) |
This output shows that the MySQL server is using mysql-bin.000001 as its binary log file. The current
log position in the log file is 1678. The values of Binlog_Do_DB and Binlog_Ignore_DB are not configured. Record the
name of the binary log file and the current position because these
values are needed when you configure the slave servers. Start the MySQL command-line client by entering the following
command: # mysql –u root –p At the prompt, enter the database password. Create a replication user on the master server that has
the privileges needed to connect and change mastership to the master
server. The slave server uses this account to connect and configure
the master/slave relationship. If the osmusr user account does not already exist, to create it, issue the following
command: mysql> create user
'osmusr'@'slave.test' identified by 'osmpass'; Next, grant the necessary privileges to allow the MySQL
slave servers to connect to the master server and establish replication:
mysql> grant
replication slave on *.* to ‘osmusr’@’slave.test’
\ identified by ‘osmpass’; The master server is now ready for the slave servers’
connection.
Configuring the Slave Servers |  |  |  |  | NOTE: The following procedure must be run on both slave servers. |  |  |  |  |
Change the server-id parameter
in the /etc/my.cnf file as follows: [mysqld] server-id=2 If you are setting up multiple slave servers, each one must
have a unique server-id value that differs from
that of the master server and from each of the other slave servers. Verify that the MySQL server on the slave server can be
restarted correctly by entering the following command: # /etc/init.d/mysql
restart The following SQL commands are used to set the master
server information on the slave server: 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; |
For this example, enter the following commands: mysql> CHANGE MASTER TO
-> MASTER_HOST='master.test',
-> MASTER_USER='osmusr',
-> MASTER_PASSWORD='osmpass',
-> MASTER_LOG_FILE='mysql-bin.000001',
-> MASTER_LOG_POS=1678;  |  |  |  |  | NOTE: In this example, specify the replication user account that you
created, the master log file name, and the log position that you recorded
previously from the output of the show master status command on the master server. |  |  |  |  |
Start the slave threads, which initiate the master/slave
server connection, by running the following command on the slave server: mysql> start slave; Run the show slave status command to
verify that the slave server is connected to the master server correctly: mysql> show slave
status\G The following output is displayed: *************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: master
Master_User: osmusr
Master_Port: 3306
… |
 |  |  |  |  | NOTE: Use the backslash G ( \G ) option with
any MySQL command to display the command output vertically rather
than horizontally. This can be particularly useful with commands that
result in a large amount of information. |  |  |  |  |
If the value of the Slave_IO_State field
is Waiting for master server to send event, the slave server has connected to the master server and will catch
up on any updates that have occurred. If the slave server was not
configured correctly, the value of Slave_IO_State is Connecting to master. If this
occurs, review the error log on the slave server for additional information.
After you configure the master server and the slave server,
perform the following steps to synchronize the database data. Create the test database, osmsdb, and
the test table, customer, on the master server
by referring to the SQL scripts in “Creating the Sample Database for MySQL”. Verify that the osmsdb database and customer table are created automatically on the slave server.
To do this, enter the following commands from the MySQL command-line
running on the slave servers: mysql> show databases; Verify that osmsdb is listed
in the output. mysql> use osmsdb; mysql> show tables; Verify that customer is listed as a table in the output. Run some SQL commands that modify the customer table on the master server, and verify that these changes are reflected
in the table on the slave server. For example, insert a record by
entering the following command on the master server: mysql> insert into customer values (1,
‘customer1’, \ ‘2000-01-01 10:10:10’, ‘table’,
1234) Verify that the SQL commands are executed automatically
on the slave server.
Monitoring Replication Status Run the following command on the master server to display
the status: mysql> show master status\G The file name and position of the bin log
file that the master server is using are displayed: *************************** 1. row ***************************
File: mysql-bin.000003
Position: 98
Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec) |
Run the following command on the master server to get
information about slave servers that are connecting to the master
server: mysql> show processlist\G The following data is displayed: *************************** 1. row ***************************
Id: 32
User: osmusr
Host: slave-1.test:32798
db: NULL
Command: Binlog Dump
Time: 5740
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL
*************************** 2. row ***************************
Id: 33
User: osmusr
Host: slave-2.test:32944
db: NULL
Command: Binlog Dump
Time: 2150
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL
*************************** 3. row ***************************
Id: 34
User: root
Host: localhost
db: NULL
Command: Query
Time: State: NULL
Info: show processlist
3 rows in set (0.00 sec) |
The output shows that two slave servers, slave-1.test and slave-2.test, have connected
to the master server, and the master server has sent all the binary
log data to both slave servers and they are both up to date. To show the status of the slave server, run the following
command on the master server mysql> show slave status\G The master server information for this slave server and its
status are displayed. If the slave server has processed all updates
from the binary log and is up to date with the master server, the
values of Master_Log_File and Read_Master_Log_Pos in the output are consistent with the output of show master
status on the master server from step 1. To show the current status of the slave server I/O thread,
run the following command from the slave server: mysql> show processlist\G *************************** 1. row ***************************
Id: 4
User: system user
Host:
db: NULL
Command: Connect
Time: 173581
State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 5
User: system user
Host:
db: NULL
Command: Connect
Time: 81990
State: Has read all relay log; waiting for the slave I/O thread to update it
Info: NULL
*************************** 3. row ***************************
Id: 225
User: root
Host: localhost
db: NULL
Command: Query
Time: 0
State: NULL
Info: show processlist
3 rows in set (0.00 sec) |
 |
The show processlist command on the slave
server displays the current status of the slave I/O thread, which
connects to the master server and writes events from the master server
to relay logs. This command also shows the status of the slave server
SQL thread, which reads events from these relay logs and enters them
into the slave server database. The values of the State field in the output indicate that the slave server I/O thread and
the slave server SQL thread have finished their tasks and are waiting
for additional updates from the master server.
Scaling MySQL Using Replication |  |
There are many different methods to scale out MySQL using replication.
The primary concern in configuring scale-out installations is how
to spread out a large number of queries across two or more replicated
slave servers. Although a single master server is responsible for all data
modification in the database, many different slave servers might be
ready to service read-only queries at any one time. This process is known as load balancing. The most popular methods
for load-balancing queries across several slave servers are: Round-robin DNS—In this method, the Domain Name
System (DNS) within the IT environment is configured to map two or
more IP addresses to a single host name. When clients query DNS for
the IP address of a given host name, DNS cycles through all the possible
IP addresses, returning one after the other with each DNS query. In
this simple and lightweight scheme, all the slave servers have the
same host name in DNS, although each has a unique IP address. When
a MySQL client wants to query the MySQL database using a slave server,
it makes the request using the host name. DNS automatically refers
the request to the next slave server IP address in turn. The shortcoming
of the round-robin load balancing scheme is that it does not take
into account any dynamic load considerations, such as how long a given
slave server is taking to service requests, whether a particular network
path is congested, or how the query load is changing over time. Hardware load balancer—A hardware load-balancer
is dedicated, custom-built hardware, sometimes referred to as an application
switch, which is capable of directing large volumes of specific application
traffic simultaneously over multiple network paths. Such a switch
is often used in large website installations to balance web page traffic
across several web servers. Similarly, this type of device may be
used to balance SQL queries across several slave servers. Hardware
load balancers use sophisticated high-speed switching fabrics and
algorithms to ensure that application traffic is routed quickly across
a network to the most appropriate slave server available. However,
these systems are costly when compared with other options. Software load balancer—A software load balancer
serves the same purpose as a hardware load balancer, but is implemented
in software on an existing system rather than on a dedicated, custom-built
switch. This represents a compromise between a round-robin system
(which is simple but offers no intelligent routing or balancing) and
a hardware load balancer (which is a very capable and fast switching
implementation but might be too costly for smaller installations). This section describes the configuration of a master/slave server
replication scheme using a software load balancer. The Linux Virtual
Server (LVS) system is a free, open-source application commonly used
to implement load-balancing solutions on Linux systems. To scale out
a MySQL installation, the replication architecture must consist of
at least three servers: a master server and two slave servers, as
shown in Figure 5. For the installation and configuration of LVS, see the LVS overview
documentation at: http://www.linuxvirtualserver.org/Documents.html
Any application that is accessing the replicated database must
have two data sources configured. One is the LVS, which acts as a
load balancer for any read queries to the slave servers, and the other
is the master server for any write queries. The MySQL master server records all write queries received from
the clients and writes corresponding updates in its binary log. This
data is then updated to the local storage. The slave servers connect
to the master server, read queries from the master server's binary
log, and execute them against their local copy of the data. When the
client-read queries arrive through the load balancer, the query results
can be found. This functionality is enabled by MySQL replication.
LVS acts as the load balancer, which is the traffic router that receives
the requests and spreads the workload among several slave servers.
By having several slave servers behind a load balancer, the network
can better handle brief surges in traffic that can otherwise overwhelm
a single server. The LVS server is fully transparent to the MySQL
clients.
|