Download Implementation of Database Replication and Binary Logging

Implementation of Database
Replication and Binary Logging
i4Life
Tomas Basham
August 13, 2012
Documentation
Database Replication and Binary Logging
Table of Contents
Implementation of Database Replication and Binary Logging ........................................................... 1
Replication Master Device ........................................................................................................................ 3
Replication Slave Device........................................................................................................................... 5
Documentation
Database Replication and Binary Logging
Replication Master Device
This section of the document is a guide through setting up the host machine within the database
replication scheme that will act as the master device. The master’s role is to wait for requests from
each slave device in the configuration for more data to replicate. When these requests are received
the master device sends SQL statements from its binary logs to the slave device for it to reconstruct
the database at its end. This setup is to be done before the database is made available to a live
system, and should therefore be done offline. After this there should be no reason to take the
database offline, except to restore the database if something was to go horribly wrong. Enabling the
MySQL process to act as a replication master is very simple, requiring only a few arguments to be
added to MySQL’s configuration file. The first step is to open up the configuration file, my.cnf, found
under the directory structure /etc/mysql/ and make the following changes:




Comment out “skip-networking” and “bind-address” (ignoring the quotes)
Uncomment “log-bin = <path/to/binary/logs>” (text in brackets will be an actual path)
Uncomment “bin-do-db” and add the name of the database to be replicated e.g. CRi4LifeDev
Uncomment “server-id = 1” (make sure that the ID is unique in the replication configuration. If
there is more than one device in this configuration, it may result in data not being replicated
across all hosts, as some hosts will be hidden behind matching IDs)
This will enable MySQL to keep binary logs of all transaction made to the database, and tells MySQL
which database is to be replicated. After these changes have been made, save the configuration file
and restart the MySQL process. Once MySQL has completely restarted, log into the MySQL shell. A
new user needs to be created in order for the replication slaves to access the MySQL database on the
master host. Having logged into the MySQL shell issue the following commands:



USE mysql
GRANT REPLICATION SLAVE ON *.* TO ‘slave_user’@’%’ IDENTIFIED BY ‘slave_password’
FLUSH PRIVILEGES
This will create a new user called “slave_user” (minus the quotes) which is identified by the password
given. This should obviously be made more secure than the example given above. Now that this is
done the host has been setup as a master host for database replication to occur. Now all that remains
to do is to make the initial transfer of all the data the database currently stores to a slave host.
Before existing the MySQL shell move to the database that is to be replicated by using the USE
syntax and run the following command:


FLUSH TABLES WITH READ LOCK
SHOW MASTER STATUS
This creates a lock on all MyISAM table such that all writes to the tables are queued up until the tables
are unlocked. This is to ensure no data is written to tables as they are read during the initial copying of
the database. The second command that was issued displays a table containing the binary log file
name that the database is currently using to log each transaction to the database, along with the
current position in the file the database is. Take note if these as they will be needed later for the
replication slave. Now that no new data can be written to the tables exist the MySQL shell and backup
the database using mysqldump as follows:

mysqldump -u root -p --opt --single-transaction “database_name” > ~/backup.sql
Documentation
Database Replication and Binary Logging
This will create a series of SQL statements that can be used to recreate the database. Remember to
change “database_name” to the name of the database that is to be backed up. After this has finished
backing up the database log back into the MySQL shell and issue the following to unlock all the tables:

UNLOCK TABLES
Lastly exit the MySQL shell and copy the backup.sql file created earlier to the host that is to be made
the replication slave.
Documentation
Database Replication and Binary Logging
Replication Slave Device
This section of the document is a guide through setting up the host machine within the database
replication scheme that will act as the slave device. The slave’s role is to send requests to the
replication master and use the returned data to recreate any changes that have been made. Once the
slave is synchronized with the master device it is to be used to make backups. The reason for this is to
make backups of the database without interrupting the replication master and therefore not
interrupting the cross-mapping tools. Once the backup is made, the slave can be started again, and
will continue to synchronize with the master from where it had left off. As with the replication master it
is very simple to setup the slave, requiring only a few arguments to be added to MySQL’s
configuration file. The first step is to open up the configuration file, my.cnf, found under the directory
structure /etc/mysql/ and make the following changes:



Uncomment “log-bin = <path/to/binary/logs>” (text in brackets will be an actual path)
Uncomment “server-id = 2” (make sure that the ID is unique in the replication configuration)
Add “log-slave-updates” underneath log-bin
By default the slave will not add to it’s binary logs transactions that are retrieved from the master
device. Therefore no binary logs are ever made on the slave device meaning they cannot be used for
incremental backups. However the third argument in the above list ensures that all transactions that
are made to the slave are logged on the slave thus making the binary logs useful. Once these
changes have been made save the configuration file and restart the MySQL process. When the
process has successfully restarted the host is now configured as a replication slave. However at this
time no updates will be fed through from the master to the slave. This is because the slave has not yet
been told where to get updates from and also does not contain the data that is currently on the master
device. In order to update the slave log into the MySQL shell and create a database matching the
database that is to be replicated (i.e. CRi4LifeDev). Then exit the MySQL shell and issue the following
command to restore the database from the backup.sql file that was created earlier:

mysql -u root -p “database_name” < backup.sql
Having run this command, substituting “database_name” from the name of the database that is to be
replicated, the database will be restored to the state of the master when the backup.sql file was
created. Once this has finished, log back into the MySQL shell to configure the slave to retrieve
updates from the replication master. This is achieved by issuing the following commands:



SLAVE STOP
CHANGE MASTER TO MASTER_HOST = ‘host_name’, MASTER_USER = ‘slave_user’,
MASTER_PASSWORD = ‘slave_password’, MASTER_LOG_FILE = ‘recorded_file_name’,
MASTER_LOG_POS = recorded_position
SLAVE START
Here several substitutions have to be made; host_name should be the hostname or IP address of the
replication master host; slave_user should be the username setup on the replication master;
slave_password should be the matching password to the user; recorded_file_name should be the
name of the file that was recorded earlier after having issued the SHOW MASTER STATUS command
within the MySQL shell on the replication master; and recorded position should be number recorded
from the same SHOW MASTER STATUS command. N.B. the single quotes above are intentional and
should remain even after substitution.
If the configuration was successful, the replication slave should now be retrieving updated from the
master.
Documentation
Database Replication and Binary Logging