Table of Contents
To use replication as a backup solution, replicate data from the master to a slave, and then back up the data slave. The slave can be paused and shut down without affecting the running operation of the master, so you can produce an effective snapshot of “live” data that would otherwise require the master to be shut down.
How you back up a database depends on its size and whether you are backing up only the data, or the data and the replication slave state so that you can rebuild the slave in the event of failure. There are therefore two choices:
If you are using replication as a solution to enable you to back up the data on the master, and the size of your database is not too large, the mysqldump tool may be suitable. See Section 2.1, “Backing Up a Slave Using mysqldump”.
For larger databases, where mysqldump would be impractical or inefficient, you can back up the raw data files instead. Using the raw data files option also means that you can back up the binary and relay logs that will enable you to recreate the slave in the event of a slave failure. For more information, see Section 2.2, “Backing Up Raw Data from a Slave”.
Another backup strategy, which can be used for either master or slave servers, is to put the server in a read-only state. The backup is performed against the read-only server, which then is changed back to its usual read/write operational status. See Section 2.3, “Backing Up a Master or Slave by Making It Read Only”.
Using mysqldump to create a copy of a database enables you to capture all of the data in the database in a format that enables the information to be imported into another instance of MySQL Server (see mysqldump — A Database Backup Program). Because the format of the information is SQL statements, the file can easily be distributed and applied to running servers in the event that you need access to the data in an emergency. However, if the size of your data set is very large, mysqldump may be impractical.
When using mysqldump, you should stop replication on the slave before starting the dump process to ensure that the dump contains a consistent set of data:
Stop the slave from processing requests. You can stop replication completely on the slave using mysqladmin:
shell> mysqladmin stop-slaveAlternatively, you can stop only the slave SQL thread to pause event execution:
shell> mysql -e 'STOP SLAVE SQL_THREAD;'This enables the slave to continue to receive data change events from the master's binary log and store them in the relay logs using the I/O thread, but prevents the slave from executing these events and changing its data. Within busy replication environments, permitting the I/O thread to run during backup may speed up the catch-up process when you restart the slave SQL thread.
Run mysqldump to dump your databases. You may either dump all databases or select databases to be dumped. For example, to dump all databases:
shell> mysqldump --all-databases > fulldb.dumpOnce the dump has completed, start slave operations again:
shell> mysqladmin start-slaveIn the preceding example, you may want to add login credentials (user name, password) to the commands, and bundle the process up into a script that you can run automatically each day.
If you use this approach, make sure you monitor the slave replication process to ensure that the time taken to run the backup does not affect the slave's ability to keep up with events from the master. See Checking Replication Status. If the slave is unable to keep up, you may want to add another slave and distribute the backup process. For an example of how to configure this scenario, see Replicating Different Databases to Different Slaves.
To guarantee the integrity of the files that are copied, backing
up the raw data files on your MySQL replication slave should
take place while your slave server is shut down. If the MySQL
server is still running, background tasks may still be updating
the database files, particularly those involving storage engines
with background processes such as InnoDB.
With InnoDB, these problems should be
resolved during crash recovery, but since the slave server can
be shut down during the backup process without affecting the
execution of the master it makes sense to take advantage of this
capability.
To shut down the server and back up the files:
Shut down the slave MySQL server:
shell> mysqladmin shutdownCopy the data files. You can use any suitable copying or archive utility, including cp, tar or WinZip. For example, assuming that the data directory is located under the current directory, you can archive the entire directory as follows:
shell> tar cf /tmp/dbbackup.tar ./dataStart the MySQL server again. Under Unix:
shell> mysqld_safe &Under Windows:
C:\> "C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld"
Normally you should back up the entire data directory for the
slave MySQL server. If you want to be able to restore the data
and operate as a slave (for example, in the event of failure of
the slave), then in addition to the slave's data, you should
also back up the slave status files,
master.info and
relay-log.info, along with the relay log
files. These files are needed to resume replication after you
restore the slave's data.
If you lose the relay logs but still have the
relay-log.info file, you can check it to
determine how far the SQL thread has executed in the master
binary logs. Then you can use CHANGE MASTER
TO with the MASTER_LOG_FILE and
MASTER_LOG_POS options to tell the slave to
re-read the binary logs from that point. This requires that the
binary logs still exist on the master server.
If your slave is replicating
LOAD DATA
INFILE statements, you should also back up any
SQL_LOAD-* files that exist in the
directory that the slave uses for this purpose. The slave needs
these files to resume replication of any interrupted
LOAD DATA
INFILE operations. The location of this directory is
the value of the
--slave-load-tmpdir option. If
the server was not started with that option, the directory
location is the value of the
tmpdir system variable.
It is possible to back up either master or slave servers in a
replication setup by acquiring a global read lock and
manipulating the read_only
system variable to change the read-only state of the server to
be backed up:
Make the server read-only, so that it processes only retrievals and blocks updates.
Perform the backup.
Change the server back to its normal read/write state.
The instructions in this section place the server to be backed up in a state that is safe for backup methods that get the data from the server, such as mysqldump (see mysqldump — A Database Backup Program). You should not attempt to use these instructions to make a binary backup by copying files directly because the server may still have modified data cached in memory and not flushed to disk.
The following instructions describe how to do this for a master server and for a slave server. For both scenarios discussed here, suppose that you have the following replication setup:
A master server M1
A slave server S1 that has M1 as its master
A client C1 connected to M1
A client C2 connected to S1
In either scenario, the statements to acquire the global read
lock and manipulate the
read_only variable are
performed on the server to be backed up and do not propagate to
any slaves of that server.
Scenario 1: Backup with a Read-Only Master
Put the master M1 in a read-only state by executing these statements on it:
mysql>FLUSH TABLES WITH READ LOCK;mysql>SET GLOBAL read_only = ON;
While M1 is in a read-only state, the following properties are true:
Requests for updates sent by C1 to M1 will block because the server is in read-only mode.
Requests for query results sent by C1 to M1 will succeed.
Making a backup on M1 is safe.
Making a backup on S1 is not safe. This server is still running, and might be processing the binary log or update requests coming from client C2
While M1 is read only, perform the backup. For example, you can use mysqldump.
After the backup operation on M1 completes, restore M1 to its normal operational state by executing these statements:
mysql>SET GLOBAL read_only = OFF;mysql>UNLOCK TABLES;
Although performing the backup on M1 is safe (as far as the backup is concerned), it is not optimal for performance because clients of M1 are blocked from executing updates.
This strategy applies to backing up a master server in a replication setup, but can also be used for a single server in a nonreplication setting.
Scenario 2: Backup with a Read-Only Slave
Put the slave S1 in a read-only state by executing these statements on it:
mysql>FLUSH TABLES WITH READ LOCK;mysql>SET GLOBAL read_only = ON;
While S1 is in a read-only state, the following properties are true:
The master M1 will continue to operate, so making a backup on the master is not safe.
The slave S1 is stopped, so making a backup on the slave S1 is safe.
These properties provide the basis for a popular backup scenario: Having one slave busy performing a backup for a while is not a problem because it does not affect the entire network, and the system is still running during the backup. In particular, clients can still perform updates on the master server, which remains unaffected by backup activity on the slave.
While S1 is read only, perform the backup. For example, you can use mysqldump.
After the backup operation on S1 completes, restore S1 to its normal operational state by executing these statements:
mysql>SET GLOBAL read_only = OFF;mysql>UNLOCK TABLES;
After the slave is restored to normal operation, it again synchronizes to the master by catching up with any outstanding updates from the binary log of the master.