MySQL备份与恢复（PDF版）

MySQL备份与恢复（PDF版）
下面文章摘录的主题：mysql日志文件，使用mysqld加相应选项来启用某种日志。

Mysql 完全备份及恢复：mysqldump对MyISAM或InnoDB完全备份，mysqlhotcopy对MyISAM完全备份。

增量备份：使用二进制日志增量备份，使用mysqlbinlog命令恢复二进制日志。

SQL语法备份及恢复。

拷贝数据文件备份（对Innodb还需拷贝日志文件）。

MyISAM表的检查与修复（另见《MySql存储引擎》）。

Innodb表的碎片整理和模糊检查点。

MySQL备份和恢复
作/译者：叶金荣
本文讨论MySQL的备份和恢复机制，以及如何维护数据表，包括最主要的两种表类型：MyISAM和Innodb，文中设计的MySQL版本为 5.0.22。

目前MySQL支持的免费备份工具有：mysqldump、mysqlhotcopy，还可以用SQL语法进行备份：BACKUP TABLE或者SELECT INTO OUTFILE，又或者备份二进制日志（binlog），还可以是直接拷贝数据文件和相关的配置文件。

MyISAM表是保存成文件的形式，因此相对比较容易备份，上面提到的几种方法都可以使用。

Innodb所有的表都保存在同一个数据文件ibdata1中（也可能是多个文件，或者是独立的表空间文件），相对来说比较不好备份，免费的方案可以是拷贝数据文件、备份binlog，或者用mysqldump。

1、mysqldump
1.1备份
mysqldump是采用SQL级别的备份机制，它将数据表导成SQL 脚本文件，在不同的MySQL版本之间升级时相对比较合适，这也是最常用的备份方法。

现在来讲一下mysqldump的一些主要参数：
1.--compatible=name
它告诉mysqldump，导出的数据将和哪种数据库或哪个旧版本的MySQL服务器相兼容。

值可以为ansi、mysql323、mysql40、postgresql、oracle、mssql、db2、maxdb、no_key_options、no_tables_options、no_field_options等，要使用几个值，用逗号将它们隔开。

当然了，它并不保证能完全兼容，而是尽量兼容。

2.--complete-insert，-c
导出的数据采用包含字段名的完整INSERT方式，也就是把所有的值都写在一行。

这么做能提高插入效率，但是可能会受到max_allowed_packet参数的影响而导致插入失败。

因此，需要谨慎使用该参数，至少我不推荐。

3.--default-character-set=charset
指定导出数据时采用何种字符集，如果数据表不是采用默认的latin1字符集的话，那么导出时必须指定该选项，否则再次导入数据后将产生乱码问题。

4.--disable-keys
告诉mysqldump在INSERT语句的开头和结尾增加/*!40000ALTER TABLE table DISABLE KEYS*/;和/*!40000ALTER TABLE table ENABLE KEYS*/;语句，这能大大提高插入语句的速度，因为它是在插入完所有数据后才重建索引的。

该选项只适合MyISAM 表。

5.--extended-insert=true|false
默认情况下，mysqldump开启--complete-insert模式，因此不想用它的的话，就使用本选项，设定它的值为false即可。

6.--hex-blob
使用十六进制格式导出二进制字符串字段。

如果有二进制数据就必须使用本选项。

影响到的字段类型有BINARY、VARBINARY、BLOB。

7.--lock-all-tables，-x
在开始导出之前，提交请求锁定所有数据库中的所有表，以保证数据的一致性。

这是一个全局读锁，并且自动关闭--single-
transaction和--lock-tables选项。

8.--lock-tables
它和--lock-all-tables类似，不过是锁定当前导出的数据表，而不是一下子锁定全部库下的表。

本选项只适用于MyISAM表，如果是Innodb表可以用--single-transaction选项。

9.--no-create-info，-t
只导出数据，而不添加CREATE TABLE语句。

10.--no-data，-d
不导出任何数据，只导出数据库表结构。

11.--opt
这只是一个快捷选项，等同于同时添加--add-drop-tables--add-locking--create-option
--disable-keys--extended-insert--lock-tables--quick--set-charset选项。

本选项能让
mysqldump很快的导出数据，并且导出的数据能很快导回。

该选项默认开启，但可以用--skip-opt禁用。

注意，如果运行mysqldump没有指定--quick或--opt选项，则会将整个结果集放在内存中。

如果导出大数据库的话可能会出现问题。

12.--quick，-q
该选项在导出大表时很有用，它强制mysqldump从服务器查询取得记录直接输出而不是取得所有记录后将它们缓存到内存中。

13.--routines，-R
导出存储过程以及自定义函数。

14.--single-transaction
该选项在导出数据之前提交一个BEGIN SQL语句，BEGIN不会阻塞任何应用程序且能保证导出时数据库的一致性状态。

它只适用于事务表，例如InnoDB和BDB。

本选项和--lock-tables选项是互斥的，因为LOCK TABLES会使任何挂起的事务隐含提交。

要想导出大表的话，应结合使用--quick选项。

15.--triggers
同时导出触发器。

该选项默认启用，用--skip-triggers禁用它。

其他参数详情请参考手册，我通常使用以下SQL来备份MyISAM 表：
/usr/local/mysql/bin/mysqldump-uyejr-pyejr\
--default-character-set=utf8--opt--extended-insert=false\
--triggers-R--hex-blob-x db_name>db_name.sql
使用以下SQL来备份Innodb表：
/usr/local/mysql/bin/mysqldump-uyejr-pyejr\
--default-character-set=utf8--opt--extended-insert=false\
--triggers-R--hex-blob--single-transaction
db_name>db_name.sql
另外，如果想要实现在线备份，还可以使用--master-data参数来实现，如下：
/usr/local/mysql/bin/mysqldump-uyejr-pyejr\
--default-character-set=utf8--opt--master-data=1\
--single-transaction--flush-logs db_name>db_name.sql
它只是在一开始的瞬间请求锁表，然后就刷新binlog了，而后在导出的文件中加入CHANGE MASTER语句来指定当前备份的binlog 位置，如果要把这个文件恢复到slave里去，就可以采用这种方法来做。

1.2还原
用mysqldump备份出来的文件是一个可以直接倒入的SQL脚本，有两种方法可以将数据导入。

1.直接用mysql客户端
例如：
/usr/local/mysql/bin/mysql-uyejr-pyejr
db_name<db_name.sql< p="">
2.用SOURCE语法
其实这不是标准的SQL语法，而是mysql客户端提供的功能，例如：
SOURCE/tmp/db_name.sql;
这里需要指定文件的绝对路径，并且必须是mysqld运行用户(例如nobody)有权限读取的文件。

2、mysqlhotcopy
2.1备份
mysqlhotcopy是一个PERL程序，最初由Tim Bunce编写。

它使用LOCK TABLES、FLUSH TABLES和cp 或scp来快速备份数据库。

它是备份数据库或单个表的最快的途径，但它只能运行在数据库文件（包括数据表定义文件、数据文件、索引文件）所在的机器上。

mysqlhotcopy只能用于备份MyISAM，并且只能运行在类Unix和NetWare系统上。

mysqlhotcopy支持一次性拷贝多个数据库，同时还支持正则表达。

以下是几个例子：
root#/usr/local/mysql/bin/mysqlhotcopy-h=localhost-
u=yejr-p=yejr\
db_name/tmp(把数据库目录db_name拷贝到/tmp下)
root#/usr/local/mysql/bin/mysqlhotcopy-h=localhost-
u=yejr-p=yejr\
db_name_1...db_name_n/tmp
root#/usr/local/mysql/bin/mysqlhotcopy-h=localhost-
u=yejr-p=yejr\
db_name./regex//tmp
更详细的使用方法请查看手册，或者调用下面的命令来查看mysqlhotcopy的帮助：
perldoc/usr/local/mysql/bin/mysqlhotcopy
注意，想要使用mysqlhotcopy，必须要有SELECT、RELOAD(要执行FLUSH TABLES)权限，并且还必须要能够有读取datadir/db_name目录的权限。

2.2还原
mysqlhotcopy备份出来的是整个数据库目录，使用时可以直接
拷贝到mysqld指定的datadir(在这里是/usr/local/mysql/data/)目录下即可，同时要注意权限的问题，如下例：
root#cp-rf db_name/usr/local/mysql/data/
root#chown-R nobody:nobody/usr/local/mysql/data/(将db_name目录的属主改成mysqld运行用户)
3、SQL语法备份
3.1备份
BACKUP TABLE语法其实和mysqlhotcopy的工作原理差不多，都是锁表，然后拷贝数据文件。

它能实现在线备份，但是效果不理想，因此不推荐使用。

它只拷贝表结构文件和数据文件，不同时拷贝索引文件，因此恢复时比较慢。

例子：
BACK TABLE tbl_name TO'/tmp/db_name/';
注意，必须要有FILE权限才能执行本SQL，并且目录/tmp/db_name/必须能被mysqld用户可写，导出的文件不能覆盖已经存在的文件，以避免安全问题。

SELECT INTO OUTFILE则是把数据导出来成为普通的文本文件，可以自定义字段间隔的方式，方便处理这些数据。

例子：
SELECT*INTO OUTFILE'/tmp/db_name/tbl_name.txt'FROM tbl_name;
注意，必须要有FILE权限才能执行本SQL，并且文件/tmp/db_name/tbl_name.txt必须能被mysqld用户可写，导出的文件不能覆盖已经存在的文件，以避免安全问题。

3.2恢复
用BACKUP TABLE方法备份出来的文件，可以运行RESTORE TABLE语句来恢复数据表。

例子：
RESTORE TABLE FROM'/tmp/db_name/';
权限要求类似上面所述。

用SELECT INTO OUTFILE方法备份出来的文件，可以运行LOAD DATA INFILE语句来恢复数据表。

例子：
LOAD DATA INFILE'/tmp/db_name/tbl_name.txt'INTO TABLE tbl_name;
权限要求类似上面所述。

导入数据之前，数据表要已经存在才行。

如果担心数据会发生重复，可以增加REPLACE关键字来替换已有记录或者用IGNORE关键字来忽略他们。

4、启用二进制日志(binlog)
采用binlog的方法相对来说更灵活，省心省力，而且还可以支持增量备份。

启用binlog时必须要重启mysqld。

首先，关闭mysqld，打开/doc/103505405.html,f，加入以下几行：server-id=1
log-bin=binlog
log-bin-index=binlog.index
然后启动mysqld就可以了。

运行过程中会产生binlog.000001以及binlog.index，前面的文件是mysqld记录所有对数据的更新操作，后面的文件则是所有binlog的索引，都不能轻易删除。

关于binlog 的信息请查看手册。

需要备份时，可以先执行一下SQL语句，让mysqld终止对当前binlog的写入，就可以把文件直接备份，这样的话就能达到增量备份的目的了：
FLUSH LOGS;
如果是备份复制系统中的从服务器，还应该备份/doc/103505405.html,和/doc/103505405.html,文件。

备份出来的binlog文件可以用MySQL提供的工具mysqlbinlog 来查看，如：
/usr/local/mysql/bin/mysqlbinlog/tmp/binlog.000001
该工具允许你显示指定的数据库下的所有SQL语句，并且还可以限定时间范围，相当的方便，详细的请查看手册。

恢复时，可以采用类似以下语句来做到：
/usr/local/mysql/bin/mysqlbinlog/tmp/binlog.000001|mysq l-uyejr-pyejr db_name
把mysqlbinlog输出的SQL语句直接作为输入来执行它。

如果你有空闲的机器，不妨采用这种方式来备份。

由于作为slave 的机器性能要求相对不是那么高，因此成本低，用低成本就能实现增量备份而且还能分担一部分数据查询压力，何乐而不为呢？
5、直接备份数据文件
相较前几种方法，备份数据文件[即直接拷贝数据文件]最为直接、快速、方便，缺点是基本上不能实现增量备份。

为了保证数据的一致性，需要在拷贝文件前，执行以下SQL语句：
FLUSH TABLES WITH READ LOCK;
也就是把内存中的数据都刷新到磁盘中，同时锁定数据表，以保证拷贝过程中不会有新的数据写入。

这种方法备份出来的数据恢复也很简单，直接拷贝回原来的数据库目录下即可。

注意，对于Innodb类型表来说，还需要备份其日志文件，即ib_logfile*文件。

因为当Innodb表损坏时，就可以依靠这些日志文件来恢复。

6、备份策略
对于中等级别业务量的系统来说，备份策略可以这么定：第一次全量备份，每天一次增量备份，每周再做一次全量备份，如此一直重复。

而对于重要的且繁忙的系统来说，则可能需要每天一次全量备份，每小时一次增量备份，甚至更频繁。

为了不影响线上业务，实现在线备份，并且能增量备份，最好的办法就是采用主从复制机制(replication)，在slave机器上做备份。

7、数据维护和灾难恢复
作为一名DBA(我目前还不是，呵呵)，最重要的工作内容之一是保证数据表能安全、稳定、高速使用。

因此，需要定期维护你的数据
表。

以下SQL语句就很有用：
CHECK TABLE或REPAIR TABLE，检查或维护MyISAM表
OPTIMIZE TABLE，优化MyISAM表
ANALYZE TABLE，分析MyISAM表
当然了，上面这些命令起始都可以通过工具myisamchk来完成，在这里不作详述。

Innodb表则可以通过执行以下语句来整理碎片，提高索引速度：ALTER TABLE tbl_name ENGINE=Innodb;
这其实是一个NULL操作，表面上看什么也不做，实际上重新整理碎片了。

通常使用的MyISAM表可以用上面提到的恢复方法来完成。

如果是索引坏了，可以用myisamchk工具来重建索引。

而对于Innodb表来说，就没这么直接了，因为它把所有的表都保存在一个表空间了。

不过Innodb 有一个检查机制叫模糊检查点，只要保存了日志文件，就能根据日志文件来修复错误。

可以在/doc/103505405.html,f文件中，增加以下参数，让mysqld在启动时自动检查日志文件：
innodb_force_recovery=4
关于该参数的信息请查看手册。

8、总结
做好数据备份，定只好合适的备份策略，这是一个DBA所做事情的一小部分，万事开头难，就从现在开始吧！
来源：/doc/103505405.html,/mysql_backup_and_reco ver
备份与恢复
本节讨论如何进行数据库备份(完全备份和增量备份)，以及如何执行表的维护。

本节描述的SQL语句语法参见第5章：数据库管理。

此处提供的大多数信息主要适合MyISAM表。

5.9.1.数据库备份
因为MySQL表保存为文件方式，很容易备份。

要想保持备份的一致性，对相关表执行LOCK TABLES操作，然后对表执行FLUSH TABLES。

参见13.4.5节，“LOCK TABLE S和UNLOCK TABLES语法”和13.5.5.2节，“FLUSH语法”。

你只需要读锁定；这样当你复制数据库目录中的文件时，允许其它客户继续查询表。

需要FLUSH TABLES语句来确保开始备份前将所有激活的索引页写入硬盘。

如果你想要进行SQL级别的表备份，你可以使用SELECT INTO...OUTFILE或BACKUP TABLE。

对于SELECT INTO...OUTFILE，输出的文件不能先存在。

对于BACKUP TABLE也如此，因为覆盖完整的文件会有安全风险。

备份数据库的另一个技术是使用mysqldump程序或mysqlhotcopy脚本。

完全备份数据库：
shell>mysqldump--tab=/path/to/some/dir--opt db_name 或：
shell>mysqlhotcopy db_name/path/to/some/dir
只要服务器不再进行更新，还可以只复制所有表文件(*.frm、*.MYD和*.MYI文件)。

mysqlhotcopy脚本使用该方法。

(但请注意如果数据库包含InnoDB表，这些方法不工作。

InnoDB不将表的内容保存到数据库目录中，mysqlhotcopy只适合MyISAM表）。

如果mysqld在运行则停止，然后用--log-bin[=file_name]选项来启动。

参见5.11.3节，“二进制日志”。

二进制日志文件中提供了执行mysqldump之后对数据库的更改进行复制所需要的信息。

对于InnoDB表，可以进行在线备份，不需要对表进行锁定；参见8.8节，“mysqldump：数据库备份程序”。

MySQL支持增量备份:需要用--log-bin选项来启动服务器以便启用二进制日志；参见5.11.3节，“二进制日志”。

当想要进行增量备份时(包含上一次完全备份或增量备份之后的所有更改)，应使用FLUSH LOGS回滚二进制日志。

然后，你需要将从最后的完全或增量备份的某个时刻到最后某个点的所有二进制日志复制到备份位置。

这
些二进制日志为增量备份；恢复时，按照下面的解释应用。

下次进行完全备份时，还应使用FLUSH LOGS或mysqlhotcopy--flushlogs回滚二进制日志。

参见8.8节，“mysqldump：数据库备份程序”和8.9节，“mysqlhotcopy：数据库备份程序”。

如果MySQL服务器为从复制服务器，则无论选择什么备份方法，当备份从机数据时，还应备份/doc/103505405.html, 和/doc/103505405.html,文件。

恢复了从机数据后，需要这些文件来继续复制。

如果从机执行复制LOAD DATA INFILE命令，你应还备份用--slave-load-tmpdir选项指定的目录中的SQL_LOAD-*文件。

(如果未指定，该位置默认为tmpdir变量值）。

从机需要这些文件来继续复制中断的LOAD DATA INFILE操作。

如果必须恢复MyISAM表，先使用REPAIR TABLE或myisamchk-r来恢复。

99.9%的情况下该方法可以工作。

如果myisamchk失败，试试下面的方法。

请注意只有用--log-bin选项启动了MySQL从而启用二进制日志它才工作；参见5.11.3节，“二进制日志”。

1.恢复原mysqldump备份，或二进制备份。

2.执行下面的命令重新更新二进制日志：
shell>mysqlbinlog hostname-bin.[0-9]*|mysql
在某些情况下，你可能只想要从某个位置重新运行某些二进制日志。

(通常你想要从恢复备份的日期重新运行所有二进制日志，查询不正确时例外)。

关于mysqlbinlog工具和如何使用它的详细信息参见8.6节，“mysqlbinlog：用于处理二进制日志文件的实用工具”。

还可以对具体文件进行选择备份：
·要想复制表，使用SELECT*INTO OUTFILE'file_name'FROM tbl_name。

·要想重载表，使用LOAD DATA INFILE'file_name'REPLACE...并恢复。

要避免复制记录，表必须有PRIMARY KEY或一个UNIQUE索引。

当新记录复制唯一键值的旧记录时，REPLACE关键字可以将旧记
录替换为新记录。

如果备份时遇到服务器性能问题，可以有帮助的一个策略是在从服务器而不是主服务器上建立复制并执行备份。

参见6.1节，“复制介绍”。

如果使用Veritas文件系统，可以这样备份：
1.从客户端程序执行FLUSH TABLES WITH READ LOCK。

2.从另一个shell执行mount vxfs snapshot。

3.从第一个客户端执行UNLOCK TABLES。

4.从快照复制文件。

5.卸载快照。

5.9.2.示例用备份与恢复策略
5.9.2.1.备份策略
5.9.2.2.为恢复进行备份
5.9.2.3.备份策略摘要
本节讨论进行备份的程序，在出现崩溃后，可以恢复数据：
·操作系统崩溃
·电源故障
·文件系统崩溃
·硬件问题(硬盘、母板等等)
该命令不包括mysqldump和mysql程序的--user和—password 等选项。

应包括必要的选项让MySQL服务器允许你连接它。

我们假定数据保存在MySQL的InnoDB存储引擎中，支持事务和自动崩溃恢复。

我们假定崩溃时MySQL服务器带负载。

如果不带负载，则不需要恢复。

出现操作系统崩溃或电源故障时，我们可以假定重启后硬盘上的MySQL?数据仍可用。

由于崩溃，InnoDB 数据文件中的数据可能不再保持一致性，但InnoDB读取它的日志并会查到挂起的提交的和未提交的事务清单，它们没有清空到数据文件中。

InnoDB自动卷回未提交的事务，并清空到它的数据文件中。

通过MySQL 错误日志将该恢复过程相关信息传达给用户。

下面的例子为日志摘录：
InnoDB:Database was not shut down normally.
InnoDB:Starting recovery from log files...
InnoDB:Starting log scan based on checkpoint at
InnoDB:log sequence number013674004
InnoDB:Doing recovery:scanned up to log sequence number013739520
InnoDB:Doing recovery:scanned up to log sequence number013805056
InnoDB:Doing recovery:scanned up to log sequence number013870592
InnoDB:Doing recovery:scanned up to log sequence number013936128
...
InnoDB:Doing recovery:scanned up to log sequence number020555264
InnoDB:Doing recovery:scanned up to log sequence number020620800
InnoDB:Doing recovery:scanned up to log sequence number020664692
InnoDB:1uncommitted transaction(s)which must be rolled back
InnoDB:Starting rollback of uncommitted transactions
InnoDB:Rolling back trx no16745
InnoDB:Rolling back of trx no16745completed
InnoDB:Rollback of uncommitted transactions completed
InnoDB:Starting an apply batch of log records to the database...
InnoDB:Apply batch completed
InnoDB:Started
mysqld:ready for connections
如果文件系统崩溃或出现硬件问题，我们可以假定重启后硬盘上的MySQL?数据不可用。

这说明MySQL未能成功启动，因为一些硬盘数据块不再可读。

在这种情况下，需要重新格式化硬盘，安装一个新的，或纠正问题。

然后需要从备份中恢复MySQL数据，这说明我们必须先做好备份。

要想确保，应及时返回并设计备份策略。

5.9.2.1.备份策略
我们都知道必须按计划定期进行备份。

可以用几个工具完全备份(在某个时间点的数据快照)MySQL。

例如，InnoDB Hot Backup为InnoDB数据文件提供在线非数据块物理备份，mysqldump提供在线逻辑备份。

这里使用mysqldump。

假定我们在星期日下午1点进行了备份，此时负荷较低。

下面的命令可以完全备份所有数据库中的所有InnoDB表：
shell>mysqldump--single-transaction--all-
databases>backup_sunday_1_PM.sql
这是在线非块备份，不会干扰对表的读写。

我们以前假定我们的表为InnoDB表，因此--single-transaction
使用一致性地读，并且保证mysqldump所看见的数据不会更改。

(其它客户端对InnoDB表进行的更改不会被mysqldump进程看见）。

如果我们还有其它类型的表，我们必须假定在备份过程中它们不会更改。

例如，对于mysql数据库中的MyISAM表，我们必须假定在备份过程中没有对MySQL账户进行管理更改。

mysqldump命令产生的.sql文件包含一系列SQL INSERT语句，可以用来重载转储的表。

需要进行完全备份，但有时不方便。

会产生大的备份文件并需要花时间来生成。

从某个角度，完全备份并不理想，因为每个成功的完全备份包括所有数据，甚至自从上一次完全备份以来没有更改的部分。

完成了初使完全备份后，进行增量备份会更有效。

这样备份文件要小得多，备份时间也较短。

不利之处是，恢复时不能只重载完全备份来恢复数据。

还必须要用增量备份来恢复增量更改。

要想进行增量备份，我们需要保存增量更改。

应使用--log-bin选项启动MySQL服务器，以便更新数据时将这些更改保存到文件中。

该
选项启用二进制日志，因此服务器写将每个更新数据的SQL语句写入MySQL 二进制日志。

让我们看看用--log-bin选项启动的已经运行多日的MySQL服务器的数据目录。

我们找到以下MySQL二进制日志文件：
-rw-rw----1guilhem guilhem1277324Nov1023:59gbichot2-bin.000001
-rw-rw----1guilhem guilhem4Nov1023:59gbichot2-bin.000002
-rw-rw----1guilhem guilhem79Nov1111:06gbichot2-bin.000003
-rw-rw----1guilhem guilhem508Nov1111:08gbichot2-bin.000004
-rw-rw----1guilhem
guilhem220047446Nov1216:47gbichot2-bin.000005
-rw-rw----1guilhem guilhem998412Nov1410:08gbichot2-bin.000006
-rw-rw----1guilhem guilhem361Nov1410:07gbichot2-bin.index
每次重启，MySQL服务器用序列中的下一个编号创建一个新的二进制日志文件。

当服务器运行时，你还可以通过执行FLUSH LOGS SQL语句或mysqladmin flush-logs命令，告诉服务器关闭当前的二进制日志文件并创建一个新文件。

mysqldump也有一个选项来清空日志。

数据目录中的.index文件包含该目录下所有MySQL二进制日志的清单。

该文件用于复制。

恢复时MySQL二进制日志很重要，因为它们是增量备份。

如果进行完全备份时确保清空了日志，则后面创建的二进制日志文件包含了备份后的所有数据更改。

让我们稍稍修改前面的mysqldump命令，让它在完全备份时能够清空MySQL二进制日志，以便转储文件包含包含新的当前的二进制日志：
shell>mysqldump--single-transaction--flush-logs--master-
data=2
--all-databases>backup_sunday_1_PM.sql
执行该命令后，数据目录则包含新的二进制日志文件，gbichot2-bin.000007。

结果.sql文件包含下列行：--Position to start replication or point-in-time恢复时y from
--CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;
因为mysqldump命令可以执行完全备份，这些行表示两件事情：·.sql文件包含所有写入gbichot2-bin.000007二进制日志文件或最新的文件之前的更改。

·备份后所记录的所有数据更改不出现在.sql 中，但出现在gbichot2-bin.000007二进制日志文件或最新的文件中。

在星期一下午1点，我们可以清空日志开始新的二进制日志文件来创建增量备份。

例如，执行mysqladmin flush-logs命令创建gbichot2-bin.000008。

星期日下午1点的完全备份和星期一下午1点之间的所有更改为文件gbichot2-bin.000007。

该增量备份很重要，因此最好将它复制到安全的地方。

(例如，备份到磁带或DVD上，或复制到另一台机器上）。

在星期二下午1点，执行另一个mysqladmin flush-logs命令。

星期一下午1点和星期二下午1点之间的所有所有更改为文件gbichot2-bin.000008(也应复制到某个安全的地方)。

MySQL二进制日志占据硬盘空间。

要想释放空间，应随时清空。

操作方法是删掉不再使用的二进制日志，例如进行完全备份时：shell>mysqldump--single-transaction--flush-logs--master-data=2
--all-databases--delete-master-
logs>backup_sunday_1_PM.sql
注释：如果你的服务器为复制主服务器，用mysqldump--delete-master-logs删掉MySQL二进制日志很危险，因为从服务器可能还没有完全处理该二进制日志的内容。

PURGE MASTER LOGS语句的描述中解释了为什么在删掉
MySQL二进制日志之前应进行确认。

参见13.6.1.1节，“PURGE MASTER LOGS语法”。

5.9.2.2.为恢复进行备份
现在假设在星期三上午8点出现了灾难性崩溃，需要使用备份文件进行恢复。

恢复时，我们首先恢复最后的完全备份(从星期日下午1点开始)。

完全备份文件是一系列SQL语句，因此恢复它很容易：shell>mysql<backup_sunday_1_pm.sql< p="">
在该点，数据恢复到星期日下午1点的状态。

要想恢复从那时起的更改，我们必须使用增量备份，也就是，gbichot2-bin.000007和gbichot2-bin.000008二进制日志文件。

根据需要从备份处取过这些文件，然后按下述方式处理：
shell>mysqlbinlog gbichot2-bin.000007gbichot2-bin.000008|mysql
我们现在将数据恢复到星期二下午1点的状态，但是从该时刻到崩溃之间的数据仍然有丢失。

要想恢复，我们需要MySQL服务器将MySQL二进制日志保存到安全的位置(RAID disks,SAN,...)，应为与数据文件的保存位置不同的地方，保证这些日志不在毁坏的硬盘上。

(也就是，我们可以用--log-bin选项启动服务器，指定一个其它物理设备上的与数据目录不同的位置。

这样，即使包含该目录的设备丢失，日志也不会丢失）。

如果我们执行了这些操作，我们手头上会有gbichot2-bin.000009文件，我们可以用它来恢复大部分最新的数据更改，而不会丢失到崩溃时的数据。

5.9.2.3.备份策略摘要
出现操作系统崩溃或电源故障时，InnoDB自己可以完成所有数据恢复工作。

但为了确保你可以睡好觉，应遵从下面的指导：·一定用--log-bin或甚至--log-bin=log_name选项运行MySQL 服务器，其中日志文件名位于某个安全媒介上，不同于数据目录所在驱动器。

如果你有这样的安全媒介，最好进行硬盘负载均衡(这样能够提高性能)。

·定期进行完全备份，使用mysqldump命令进行在线非块备份。

·用FLUSH LOGS或mysqladmin flush-logs清空日志进行定期增量备份。

5.9.3.自动恢复
5.9.3.1.指定恢复时间
5.9.3.2.指定恢复位置
如果MySQL服务器启用了二进制日志，你可以使用mysqlbinlog 工具来恢复从指定的时间点开始(例如，从你最后一次备份)直到现在或另一个指定的时间点的数据。

关于启用二进制日志的信息，参见5.11.3节，
“二进制日志”。

对于mysqlbinlog的详细信息，参见8.6节，“mysqlbinlog：用于处理二进制日志文件的实用工具”。

要想从二进制日志恢复数据，你需要知道当前二进制日志文件的路径和文件名。

一般可以从选项文件(即/doc/103505405.html,f or my.ini，取决于你的系统)中找到路径。

如果未包含在选项文件中，当服务器启动时，可以在命令行中以选项的形式给出。

启用二进制日志的选项为--log-bin。

要想确定当前的二进制日志文件的文件名，输入下面的MySQL语句：SHOW BINLOG EVENTS\G
你还可以从命令行输入下面的内容：
mysql--user=root-pmy_pwd-e'SHOW BINLOG EVENTS\G'
将密码my_pwd替换为服务器的root密码。

5.9.3.1.指定恢复时间
对于MySQL4.1.4，可以在mysqlbinlog语句中通过--start-date 和--stop-date选项指定DATETIME格式的起止时间。

举例说明，假设在今天上午10:00(今天是2005年4月20日)，执行SQL语句来删除一个大表。

要想恢复表和数据，你可以恢复前晚上的备份，并输入：mysqlbinlog--stop-date="2005-04-
209:59:59"/var/log/mysql/bin.123456|mysql-u root–pmypwd [stop-date稍早于重大删除时间即可]
该命令将恢复截止到在--stop-date选项中以DATETIME格式给。