Oracle 5.0 Reference Manual page 641

For storage engines that represent each table using its own files, tables can be backed up by copying
those files. For example,
(*.frm, *.MYD, and
*.MYI
relevant tables:
LOCK TABLES tbl_list READ;
FLUSH TABLES tbl_list;
You need only a read lock; this enables other clients to continue to query the tables while you are
making a copy of the files in the database directory. The
to ensure that the all active index pages are written to disk before you start the backup. See
Section 13.3.5, "LOCK TABLES
You can also create a binary backup simply by copying all table files, as long as the server isn't
updating anything. The
methods do not work if your database contains
tables because
InnoDB
Also, even if the server is not actively updating data,
memory and not flushed to disk.)
Making Delimited-Text File Backups
To create a text file containing a table's data, you can use
tbl_name. The file is created on the MySQL server host, not the client host. For this statement,
FROM
the output file cannot already exist because permitting files to be overwritten constitutes a security risk.
See Section 13.2.8, "SELECT
data, not the table structure.
Another way to create text data files (along with files containing
backed up tables) is to use
Data in Delimited-Text Format with
To reload a delimited-text data file, use
Making Incremental Backups by Enabling the Binary Log
MySQL supports incremental backups: You must start the server with the
to enable binary logging; see
information you need to replicate changes to the database that are made subsequent to the point at
which you performed a backup. At the moment you want to make an incremental backup (containing
all changes that happened since the last full or incremental backup), you should rotate the binary log
by using LOGS. This done, you need to copy to the backup location all binary logs which range
FLUSH
from the one of the moment of the last full or incremental backup to the last but one. These binary logs
are the incremental backup; at restore time, you apply them as explained in
Time (Incremental) Recovery Using the Binary
also rotate the binary log using
flushlog. See Section 4.5.4,
"mysqlhotcopy — A Database Backup
Making Backups Using Replication Slaves
If you have performance problems with your master server while making backups, one strategy that
can help is to set up replication and perform backups on the slave rather than on the master. See
Section 16.3.1, "Using Replication for
If you are backing up a slave replication server, you should back up its
files when you back up the slave's databases, regardless of the backup method you
log.info
choose. These information files are always needed to resume replication after you restore the slave's
data. If your slave is replicating
files that exist in the directory that the slave uses for this purpose. The slave needs these
SQL_LOAD-*
Database Backup Methods
tables are stored as files, so it is easy to do a backup by copying files
MyISAM
files). To get a consistent backup, stop the server or lock and flush the
and
UNLOCK TABLES
script uses this method. (But note that table file copying
mysqlhotcopy
does not necessarily store table contents in database directories.
InnoDB
Syntax". This method works for any kind of data file, but saves only table
with the
mysqldump
mysqldump".
LOAD DATA INFILE
Section 5.2.3, "The Binary
FLUSH LOGS, mysqldump
"mysqldump — A Database Backup
Program".
Backups".
LOAD DATA INFILE
621
FLUSH TABLES
Syntax", and Section 13.7.6.2,
tables.
InnoDB mysqlhotcopy
may still have modified data cached in
InnoDB
SELECT * INTO OUTFILE 'file_name'
CREATE TABLE
[305] option. See
--tab
or mysqlimport.
Log". The binary log files provide you with the
Log". The next time you do a full backup, you should
--flush-logs, or
Program", and
statements, you should also back up any
statement is needed
"FLUSH
does not work for
statements for the
Section 7.4.3, "Dumping
[1467] option
--log-bin
Section 7.5, "Point-in-
mysqlhotcopy --
Section 4.6.9,
and
master.info relay-
Syntax".