MySQL备份与恢复(PDF版)
2024-03-11
来源：六九路网
知博网zhiblog.comLinux专题下面文章摘录的主题：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语法进行备份：BACKUPTABLE或者SELECTINTOOUTFILE，又或者备份二进制日志（binlog），还可以是直接拷贝数据文件和相关的配置文件。MyISAM表是保存成文件的形式，因此相对比较容易备份，上面提到的几种方法都可以使用。Innodb所有的表都保存在同一个数据文件ibdata1中（也可能是多个文件，或者是独立的表空间文件），相对来说比较不好备份，免费的方案可以是拷贝数据文件、备份binlog，或者用mysqldump。1、mysqldump1.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语句的开头和结尾增加/*!40000ALTERTABLEtableDISABLEKEYS*/;和/*!40000ALTERTABLEtableENABLEKEYS*/;语句，这能大大提高插入语句的速度，因为它是在插入完所有数据后才重建索引的。该选项只适合MyISAM表。5.--extended-insert=true|false默认情况下，mysqldump开启--complete-insert模式，因此不想用它的的话，就使用本选项，设定它的值为false即可。6.--hex-blob知博网zhiblog.comBINARY、VARBINARY、BLOB。7.--lock-all-tables，-xLinux专题使用十六进制格式导出二进制字符串字段。如果有二进制数据就必须使用本选项。影响到的字段类型有在开始导出之前，提交请求锁定所有数据库中的所有表，以保证数据的一致性。这是一个全局读锁，并且自动关闭--single-transaction和--lock-tables选项。8.--lock-tables它和--lock-all-tables类似，不过是锁定当前导出的数据表，而不是一下子锁定全部库下的表。本选项只适用于MyISAM表，如果是Innodb表可以用--single-transaction选项。9.--no-create-info，-t只导出数据，而不添加CREATETABLE语句。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该选项在导出数据之前提交一个BEGINSQL语句，BEGIN不会阻塞任何应用程序且能保证导出时数据库的一致性状态。它只适用于事务表，例如InnoDB和BDB。本选项和--lock-tables选项是互斥的，因为LOCKTABLES会使任何挂起的事务隐含提交。要想导出大表的话，应结合使用--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-xdb_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-transactiondb_name>db_name.sql另外，如果想要实现在线备份，还可以使用--master-data参数来实现，如下：知博网zhiblog.com/usr/local/mysql/bin/mysqldump-uyejr-pyejr\\--default-character-set=utf8--opt--master-data=1\\--single-transaction--flush-logsdb_name>db_name.sqlLinux专题它只是在一开始的瞬间请求锁表，然后就刷新binlog了，而后在导出的文件中加入CHANGEMASTER语句来指定当前备份的binlog位置，如果要把这个文件恢复到slave里去，就可以采用这种方法来做。1.2还原用mysqldump备份出来的文件是一个可以直接倒入的SQL脚本，有两种方法可以将数据导入。1.例如：/usr/local/mysql/bin/mysql-uyejr-pyejrdb_name
mysqldump--tab=/path/to/some/dir--optdb_name或：shell>mysqlhotcopydb_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：数据库备份程序”。知博网zhiblog.comLinux专题MySQL支持增量备份:需要用--log-bin选项来启动服务器以便启用二进制日志；参见5.11.3节，“二进制日志”。当想要进行增量备份时(包含上一次完全备份或增量备份之后的所有更改)，应使用FLUSHLOGS回滚二进制日志。然后，你需要将从最后的完全或增量备份的某个时刻到最后某个点的所有二进制日志复制到备份位置。这些二进制日志为增量备份；恢复时，按照下面的解释应用。下次进行完全备份时，还应使用FLUSHLOGS或mysqlhotcopy--flushlogs回滚二进制日志。参见8.8节，“mysqldump：数据库备份程序”和8.9节，“mysqlhotcopy：数据库备份程序”。如果MySQL服务器为从复制服务器，则无论选择什么备份方法，当备份从机数据时，还应备份master.info和relay-log.info文件。恢复了从机数据后，需要这些文件来继续复制。如果从机执行复制LOADDATAINFILE命令，你应还备份用--slave-load-tmpdir选项指定的目录中的SQL_LOAD-*文件。(如果未指定，该位置默认为tmpdir变量值）。从机需要这些文件来继续复制中断的LOADDATAINFILE操作。如果必须恢复MyISAM表，先使用REPAIRTABLE或myisamchk-r来恢复。99.9%的情况下该方法可以工作。如果myisamchk失败，试试下面的方法。请注意只有用--log-bin选项启动了MySQL从而启用二进制日志它才工作；参见5.11.3节，“二进制日志”。1.2.恢复原mysqldump备份，或二进制备份。执行下面的命令重新更新二进制日志：shell>mysqlbinloghostname-bin.[0-9]*|mysql在某些情况下，你可能只想要从某个位置重新运行某些二进制日志。(通常你想要从恢复备份的日期重新运行所有二进制日志，查询不正确时例外)。关于mysqlbinlog工具和如何使用它的详细信息参见8.6节，“mysqlbinlog：用于处理二进制日志文件的实用工具”。还可以对具体文件进行选择备份：··要想复制表，使用SELECT*INTOOUTFILE'file_name'FROMtbl_name。要想重载表，使用LOADDATAINFILE'file_name'REPLACE...并恢复。要避免复制记录，表必须有PRIMARYKEY或一个UNIQUE索引。当新记录复制唯一键值的旧记录时，REPLACE关键字可以将旧记录替换为新记录。如果备份时遇到服务器性能问题，可以有帮助的一个策略是在从服务器而不是主服务器上建立复制并执行备份。参见6.1节，“复制介绍”。如果使用Veritas文件系统，可以这样备份：1.2.3.4.5.从客户端程序执行FLUSHTABLESWITHREADLOCK。从另一个shell执行mountvxfssnapshot。从第一个客户端执行UNLOCKTABLES。从快照复制文件。卸载快照。5.9.2.示例用备份与恢复策略5.9.2.1.备份策略5.9.2.2.为恢复进行备份5.9.2.3.备份策略摘要本节讨论进行备份的程序，在出现崩溃后，可以恢复数据：···操作系统崩溃电源故障文件系统崩溃知博网zhiblog.com·硬件问题(硬盘、母板等等)Linux专题该命令不包括mysqldump和mysql程序的--user和—password等选项。应包括必要的选项让MySQL服务器允许你连接它。我们假定数据保存在MySQL的InnoDB存储引擎中，支持事务和自动崩溃恢复。我们假定崩溃时MySQL服务器带负载。如果不带负载，则不需要恢复。出现操作系统崩溃或电源故障时，我们可以假定重启后硬盘上的MySQLś数据仍可用。由于崩溃，InnoDB数据文件中的数据可能不再保持一致性，但InnoDB读取它的日志并会查到挂起的提交的和未提交的事务清单，它们没有清空到数据文件中。InnoDB自动卷回未提交的事务，并清空到它的数据文件中。通过MySQL错误日志将该恢复过程相关信息传达给用户。下面的例子为日志摘录：InnoDB:Databasewasnotshutdownnormally.InnoDB:Startingrecoveryfromlogfiles...InnoDB:StartinglogscanbasedoncheckpointatInnoDB:logsequencenumber013674004InnoDB:Doingrecovery:scanneduptologsequencenumber013739520InnoDB:Doingrecovery:scanneduptologsequencenumber013805056InnoDB:Doingrecovery:scanneduptologsequencenumber013870592InnoDB:Doingrecovery:scanneduptologsequencenumber013936128...InnoDB:Doingrecovery:scanneduptologsequencenumber020555264InnoDB:Doingrecovery:scanneduptologsequencenumber020620800InnoDB:Doingrecovery:scanneduptologsequencenumber020664692InnoDB:1uncommittedtransaction(s)whichmustberolledbackInnoDB:StartingrollbackofuncommittedtransactionsInnoDB:Rollingbacktrxno16745InnoDB:Rollingbackoftrxno16745completedInnoDB:RollbackofuncommittedtransactionscompletedInnoDB:Startinganapplybatchoflogrecordstothedatabase...InnoDB:ApplybatchcompletedInnoDB:Startedmysqld:readyforconnections如果文件系统崩溃或出现硬件问题，我们可以假定重启后硬盘上的MySQLś数据不可用。这说明MySQL未能成功启动，因为一些硬盘数据块不再可读。在这种情况下，需要重新格式化硬盘，安装一个新的，或纠正问题。然后需要从备份中恢复MySQL数据，这说明我们必须先做好备份。要想确保，应及时返回并设计备份策略。5.9.2.1.备份策略我们都知道必须按计划定期进行备份。可以用几个工具完全备份(在某个时间点的数据快照)MySQL。例如，InnoDBHotBackup为InnoDB数据文件提供在线非数据块物理备份，mysqldump提供在线逻辑备份。这里使用mysqldump。假定我们在星期日下午1点进行了备份，此时负荷较低。下面的命令可以完全备份所有数据库中的所有InnoDB表：shell>mysqldump--single-transaction--all-databases>backup_sunday_1_PM.sql这是在线非块备份，不会干扰对表的读写。我们以前假定我们的表为InnoDB表，因此--single-transaction知博网zhiblog.comLinux专题使用一致性地读，并且保证mysqldump所看见的数据不会更改。(其它客户端对InnoDB表进行的更改不会被mysqldump进程看见）。如果我们还有其它类型的表，我们必须假定在备份过程中它们不会更改。例如，对于mysql数据库中的MyISAM表，我们必须假定在备份过程中没有对MySQL账户进行管理更改。mysqldump命令产生的.sql文件包含一系列SQLINSERT语句，可以用来重载转储的表。需要进行完全备份，但有时不方便。会产生大的备份文件并需要花时间来生成。从某个角度，完全备份并不理想，因为每个成功的完全备份包括所有数据，甚至自从上一次完全备份以来没有更改的部分。完成了初使完全备份后，进行增量备份会更有效。这样备份文件要小得多，备份时间也较短。不利之处是，恢复时不能只重载完全备份来恢复数据。还必须要用增量备份来恢复增量更改。要想进行增量备份，我们需要保存增量更改。应使用--log-bin选项启动MySQL服务器，以便更新数据时将这些更改保存到文件中。该选项启用二进制日志，因此服务器写将每个更新数据的SQL语句写入MySQL二进制日志。让我们看看用--log-bin选项启动的已经运行多日的MySQL服务器的数据目录。我们找到以下MySQL二进制日志文件：-rw-rw----1guilhemguilhem-rw-rw----1guilhemguilhem-rw-rw----1guilhemguilhem-rw-rw----1guilhemguilhem1277324Nov1023:59gbichot2-bin.0000014Nov1023:59gbichot2-bin.00000279Nov1111:06gbichot2-bin.000003508Nov1111:08gbichot2-bin.000004-rw-rw----1guilhemguilhem220047446Nov1216:47gbichot2-bin.000005-rw-rw----1guilhemguilhem-rw-rw----1guilhemguilhem998412Nov1410:08gbichot2-bin.000006361Nov1410:07gbichot2-bin.index每次重启，MySQL服务器用序列中的下一个编号创建一个新的二进制日志文件。当服务器运行时，你还可以通过执行FLUSHLOGSSQL语句或mysqladminflush-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文件包含下列行：--Positiontostartreplicationorpoint-in-time恢复时yfrom--CHANGEMASTERTOMASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;因为mysqldump命令可以执行完全备份，这些行表示两件事情：··.sql文件包含所有写入gbichot2-bin.000007二进制日志文件或最新的文件之前的更改。备份后所记录的所有数据更改不出现在.sql中，但出现在gbichot2-bin.000007二进制日志文件或最新的文件中。在星期一下午1点，我们可以清空日志开始新的二进制日志文件来创建增量备份。例如，执行mysqladminflush-logs命令创建gbichot2-bin.000008。星期日下午1点的完全备份和星期一下午1点之间的所有更改为文件gbichot2-bin.000007。该增量备份很重要，因此最好将它复制到安全的地方。(例如，备份到磁带或DVD上，或复制到另一台机器上）。在星期二下午1点，执行另一个mysqladminflush-logs命令。知博网zhiblog.com的地方)。Linux专题星期一下午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二进制日志很危险，因为从服务器可能还没有完全处理该二进制日志的内容。PURGEMASTERLOGS语句的描述中解释了为什么在删掉MySQL二进制日志之前应进行确认。参见13.6.1.1节，“PURGEMASTERLOGS语法”。5.9.2.2.为恢复进行备份现在假设在星期三上午8点出现了灾难性崩溃，需要使用备份文件进行恢复。恢复时，我们首先恢复最后的完全备份(从星期日下午1点开始)。完全备份文件是一系列SQL语句，因此恢复它很容易：shell>mysqlmysqlbinloggbichot2-bin.000007gbichot2-bin.000008|mysql我们现在将数据恢复到星期二下午1点的状态，但是从该时刻到崩溃之间的数据仍然有丢失。要想恢复，我们需要MySQL服务器将MySQL二进制日志保存到安全的位置(RAIDdisks,SAN,...)，应为与数据文件的保存位置不同的地方，保证这些日志不在毁坏的硬盘上。(也就是，我们可以用--log-bin选项启动服务器，指定一个其它物理设备上的与数据目录不同的位置。这样，即使包含该目录的设备丢失，日志也不会丢失）。如果我们执行了这些操作，我们手头上会有gbichot2-bin.000009文件，我们可以用它来恢复大部分最新的数据更改，而不会丢失到崩溃时的数据。5.9.2.3.备份策略摘要出现操作系统崩溃或电源故障时，InnoDB自己可以完成所有数据恢复工作。但为了确保你可以睡好觉，应遵从下面的指导：·一定用--log-bin或甚至--log-bin=log_name选项运行MySQL服务器，其中日志文件名位于某个安全媒介上，不同于数据目录所在驱动器。如果你有这样的安全媒介，最好进行硬盘负载均衡(这样能够提高性能)。··定期进行完全备份，使用mysqldump命令进行在线非块备份。用FLUSHLOGS或mysqladminflush-logs清空日志进行定期增量备份。5.9.3.自动恢复5.9.3.1.指定恢复时间5.9.3.2.指定恢复位置如果MySQL服务器启用了二进制日志，你可以使用mysqlbinlog工具来恢复从指定的时间点开始(例如，从你最后一次备份)直到现在或另一个指定的时间点的数据。关于启用二进制日志的信息，参见5.11.3节，知博网zhiblog.com的实用工具”。Linux专题“二进制日志”。对于mysqlbinlog的详细信息，参见8.6节，“mysqlbinlog：用于处理二进制日志文件要想从二进制日志恢复数据，你需要知道当前二进制日志文件的路径和文件名。一般可以从选项文件(即my.cnformy.ini，取决于你的系统)中找到路径。如果未包含在选项文件中，当服务器启动时，可以在命令行中以选项的形式给出。启用二进制日志的选项为--log-bin。要想确定当前的二进制日志文件的文件名，输入下面的MySQL语句：SHOWBINLOGEVENTS\\G你还可以从命令行输入下面的内容：mysql--user=root-pmy_pwd-e'SHOWBINLOGEVENTS\\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-uroot–pmypwd[stop-date稍早于重大删除时间即可]该命令将恢复截止到在--stop-date选项中以DATETIME格式给出的日期和时间的所有数据。如果你没有检测到几个小时后输入的错误的SQL语句，可能你想要恢复后面发生的活动。根据这些，你可以用起始日期和时间再次运行mysqlbinlog：mysqlbinlog--start-date=\"2005-04-2010:01:00\"/var/log/mysql/bin.123456|mysql-uroot-pmypwd[恢复重大删除语句后的所有更改]在该行中，从上午10:01登录的SQL语句将运行。组合执行前夜的转储文件和mysqlbinlog的两行可以将所有数据恢复到上午10:00前一秒钟。你应检查日志以确保时间确切。下一节介绍如何实现。5.9.3.2.指定恢复位置也可以不指定日期和时间，而使用mysqlbinlog的选项--start-position和--stop-position来指定日志位置。它们的作用与起止日选项相同，不同的是给出了从日志起的位置号。使用日志位置是更准确的恢复方法，特别是当由于破坏性SQL语句同时发生许多事务的时候。要想确定位置号，可以运行mysqlbinlog寻找执行了不期望的事务的时间范围，但应将结果重新指向文本文件以便进行检查。操作方法为：mysqlbinlog--start-date=\"2005-04-209:55:00\"--stop-date=\"2005-04-2010:05:00\"\\/var/log/mysql/bin.123456>/tmp/mysql_restore.sql该命令将在/tmp目录创建小的文本文件，将显示执行了错误的SQL语句时的SQL语句。你可以用文本编辑器打开该文件，寻找你不要想重复的语句。如果二进制日志中的位置号用于停止和继续恢复操作，应进行注释。用log_pos加一个数字来标记位置。使用位置号恢复了以前的备份文件后，你应从命令行输入下面内容：mysqlbinlog--stop-position=\"368312\"/var/log/mysql/bin.123456\\|mysql-uroot-pmypwdmysqlbinlog--start-position=\"368315\"/var/log/mysql/bin.123456\\|mysql-uroot-pmypwd\\上面的第1行将恢复到停止位置为止的所有事务。下一行将恢复从给定的起始位置直到二进制日志结束的知博网zhiblog.com关MySQL日志将反应事务执行的原时间。Linux专题所有事务。因为mysqlbinlog的输出包括每个SQL语句记录之前的SETTIMESTAMP语句，恢复的数据和相来源：http://blog.sina.com.cn/s/blog_4d22b9720100c4he.html来源：http://blog.sina.com.cn/s/blog_4d22b9720100c4hd.htmlMySQL日志文件5.11.1.错误日志5.11.2.通用查询日志5.11.3.二进制日志5.11.4.慢速查询日志5.11.5.日志文件维护MySQL有几个不同的日志文件，可以帮助你找出mysqld内部发生的事情：日志文件错误日志查询日志更新日志记入文件中的信息类型记录启动、运行或停止mysqld时出现的问题。记录建立的客户端连接和执行的语句。记录更改数据的语句。不赞成使用该日志。（在MySQL5.1中不再使用）二进制日志记录所有更改数据的语句。还用于复制。慢日志记录所有执行时间超过long_query_time秒的所有查询或不使用索引的查询。默认情况下，所有日志创建于mysqld数据目录中。通过刷新日志，你可以强制mysqld来关闭和重新打开日志文件（或者在某些情况下切换到一个新的日志）。当你执行一个FLUSHLOGS语句或执行mysqladminflush-logs或mysqladminrefresh时，出现日志刷新。参见13.5.5.2节，“FLUSH语法”。如果你正使用MySQL复制功能，从复制服务器将维护更多日志文件，被称为接替日志。相关讨论参见第6章：MySQL中的复制。5.11.1.错误日志错误日志文件包含了当mysqld启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。如果mysqld莫名其妙地死掉并且mysqld_safe需要重新启动它，mysqld_safe在错误日志中写入一条restartedmysqld消息。如果mysqld注意到需要自动检查或者修复一个表，则错误日志中写入一条消息。在一些操作系统中，如果mysqld死掉，错误日志包含堆栈跟踪信息。跟踪信息可以用来确定mysqld死掉的地方。参见E.1.4节，“使用堆栈跟踪”。可以用--log-error[=file_name]选项来指定mysqld保存错误日志文件的位置。如果没有给定file_name值，mysqld使用错误日志名host_name.err并在数据目录中写入日志文件。如果你执行FLUSHLOGS，错误日志用-old重新命名后缀并且mysqld创建一个新的空日志文件。(如果未给出--log-error选项，则不会重新命名）。如果不指定--log-error，或者(在Windows中)如果你使用--console选项，错误被写入标准错误输出stderr。通常标准输出为你的终端。在Windows中，如果未给出--console选项，错误输出总是写入.err文件。知博网zhiblog.com5.11.2.通用查询日志Linux专题如果你想要知道mysqld内部发生了什么，你应该用--log[=file_name]或-l[file_name]选项启动它。如果没有给定file_name的值，默认名是host_name.log。所有连接和语句被记录到日志文件。当你怀疑在客户端发生了错误并想确切地知道该客户端发送给mysqld的语句时，该日志可能非常有用。mysqld按照它接收的顺序记录语句到查询日志。这可能与执行的顺序不同。这与更新日志和二进制日志不同，它们在查询执行后，但是任何一个锁释放之前记录日志。(查询日志还包含所有语句，而二进制日志不包含只查询数据的语句）。服务器重新启动和日志刷新不会产生新的一般查询日志文件(尽管刷新关闭并重新打开一般查询日志文件)。在Unix中，你可以通过下面的命令重新命名文件并创建一个新文件：shell>mvhostname.loghostname-old.logshell>mysqladminflush-logsshell>cphostname-old.logto-backup-directoryshell>rmhostname-old.log在Windows中，服务器打开日志文件期间你不能重新命名日志文件。你必须先停止服务器然后重新命名日志文件。然后，重启服务器来创建新的日志文件。5.11.3.二进制日志二进制日志以一种更有效的格式，并且是事务安全的方式包含更新日志中可用的所有信息。二进制日志包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个DELETE）的所有语句。语句以“事件”的形式保存，它描述数据更改。注释：二进制日志已经代替了老的更新日志，更新日志在MySQL5.1中不再使用。二进制日志还包含关于每个更新数据库的语句的执行时间信息。它不包含没有修改任何数据的语句。如果你想要记录所有语句（例如，为了识别有问题的查询），你应使用一般查询日志。参见5.11.2节，“通用查询日志”。二进制日志的主要目的是在恢复时能够最大可能地更新数据库，因为二进制日志包含备份后[指完全备份后，如使用mysqldump。二进制日志可作为增量备份]进行的所有更新。二进制日志还用于在主复制服务器上记录所有将发送给从服务器的语句。参见第6章：MySQL中的复制。运行服务器时若启用二进制日志则性能大约慢1%。但是，二进制日志的好处，即用于恢复并允许设置复制超过了这个小小的性能损失。当用--log-bin[=file_name]选项启动时，mysqld写入包含所有更新数据的SQL命令的日志文件。如果未给出file_name值，默认名为-bin后面所跟的主机名。如果给出了文件名，但没有包含路径，则文件被写入数据目录。建议指定一个文件名，原因参见A.8.1节，“MySQL中的打开事宜”。如果你在日志名中提供了扩展名(例如，--log-bin=file_name.extension)，则扩展名被悄悄除掉并忽略。mysqld在每个二进制日志名后面添加一个数字扩展名。每次你启动服务器或刷新日志时该数字则增加。如果当前的日志大小达到max_binlog_size，还会自动创建新的二进制日志。如果你正使用大的事务，二进制日志还会超过max_binlog_size：事务全写入一个二进制日志中，绝对不要写入不同的二进制日志中。为了能够知道还使用了哪个不同的二进制日志文件，mysqld还创建一个二进制日志索引文件，包含所有使用的二进制日志文件的文件名。默认情况下与二进制日志文件的文件名相同，扩展名为'.index'。你可以知博网zhiblog.com编辑该文件；如果这样做将会使mysqld变得混乱。Linux专题用--log-bin-index[=file_name]选项更改二进制日志索引文件的文件名。当mysqld在运行时，不应手动可以用RESETMASTER语句删除所有二进制日志文件，或用PURGEMASTERLOGS只删除部分二进制文件。参见13.5.5.5节，“RESET语法”和13.6.1节，“用于控制主服务器的SQL语句”。二进制日志格式有一些已知限制，会影响从备份恢复。参见6.7节，“复制特性和已知问题”。保存程序和触发器的二进制日志的描述参见20.4节，“存储子程序和触发程序的二进制日志功能”。可以使用下面的mysqld选项来影响记录到二进制日志的内容。又见选项后面的讨论。·--binlog-do-db=db_name告诉主服务器，如果当前的数据库(即USE选定的数据库)是db_name，应将更新记录到二进制日志中。其它所有没有明显指定的数据库被忽略。如果使用该选项，你应确保只对当前的数据库进行更新。对于CREATEDATABASE、ALTERDATABASE和DROPDATABASE语句，有一个例外，即通过操作的数据库来决定是否应记录语句，而不是用当前的数据库。一个不能按照期望执行的例子：如果用binlog-do-db=sales启动服务器，并且执行USEprices;UPDATEsales.januarySETamount=amount+1000；，该语句不写入二进制日志。·--binlog-ignore-db=db_name告诉主服务器，如果当前的数据库(即USE选定的数据库)是db_name，不应将更新保存到二进制日志中。如果你使用该选项，你应确保只对当前的数据库进行更新。一个不能按照你期望的执行的例子：如果服务器用binlog-ignore-db=sales启动，并且执行USEprices;UPDATEsales.januarySETamount=amount+1000；，该语句不写入二进制日志。类似于--binlog-do-db，对于CREATEDATABASE、ALTERDATABASE和DROPDATABASE语句，有一个例外，即通过操作的数据库来决定是否应记录语句，而不是用当前的数据库。要想记录或忽视多个数据库，使用多个选项，为每个数据库指定相应的选项。服务器根据下面的规则对选项进行评估，以便将更新记录到二进制日志中或忽视。请注意对于CREATE/ALTER/DROPDATABASE语句有一个例外。在这些情况下，根据以下规则，所创建、修改或删除的数据库将代替当前的数据库。1.··2.是否有binlog-do-db或binlog-ignore-db规则?没有：将语句写入二进制日志并退出。有：执行下一步。有一些规则(binlog-do-db或binlog-ignore-db或二者都有)。当前有一个数据库(USE是否选择了数据库?)?··3.·oo·4.··没有：不要写入语句，并退出。有：执行下一步。有当前的数据库。是否有binlog-do-db规则?有：当前的数据库是否匹配binlog-do-db规则?有：写入语句并退出。没有：不要写入语句，退出。No：执行下一步。有一些binlog-ignore-db规则。当前的数据库是否匹配binlog-ignore-db规则?有：不要写入语句，并退出。没有：写入查询并退出。知博网zhiblog.com说，binlog-do-db有时可以表示“忽视其它数据库”)。Linux专题例如，只用binlog-do-db=sales运行的服务器不将当前数据库不为sales的语句写入二进制日志(换句话如果你正进行复制，应确保没有从服务器在使用旧的二进制日志文件，方可删除它们。一种方法是每天一次执行mysqladminflush-logs并删除三天前的所有日志。可以手动删除，或最好使用PURGEMASTERLOGS(参见13.6.1节，“用于控制主服务器的SQL语句”)，该语句还会安全地更新二进制日志索引文件(可以采用日期参数)。具有SUPER权限的客户端可以通过SETSQL_LOG_BIN=0语句禁止将自己的语句记入二进制记录。参见13.5.3节，“SET语法”。你可以用mysqlbinlog实用工具检查二进制日志文件。如果你想要重新处理日志止的语句，这很有用。例如，可以从二进制日志更新MySQL服务器，方法如下：shell>mysqlbinloglog-file|mysql-hserver_name关于mysqlbinlog实用工具的详细信息以及如何使用它，参见8.6节，“mysqlbinlog：用于处理二进制日志文件的实用工具”。如果你正使用事务，必须使用MySQL二进制日志进行备份，而不能使用旧的更新日志。查询结束后、锁定被释放前或提交完成后则立即记入二进制日志。这样可以确保按执行顺序记入日志。对非事务表的更新执行完毕后立即保存到二进制日志中。对于事务表，例如BDB或InnoDB表，所有更改表的更新(UPDATE、DELETE或INSERT)被缓存起来，直到服务器接收到COMMIT语句。在该点，执行完COMMIT之前，mysqld将整个事务写入二进制日志。当处理事务的线程启动时，它为缓冲查询分配binlog_cache_size(全局变量)大小的内存。如果语句大于该值，线程则打开临时文件来保存事务。线程结束后临时文件被删除。Binlog_cache_use状态变量显示了使用该缓冲区(也可能是临时文件)保存语句的事务的数量。Binlog_cache_disk_use状态变量显示了这些事务中实际上有多少必须使用临时文件。这两个变量可以用于将binlog_cache_size调节到足够大的值，以避免使用临时文件。max_binlog_cache_size(默认4GB)可以用来限制用来缓存多语句事务的缓冲区总大小。如果某个事务大于该值，将会失败并回滚。如果你正使用更新日志或二进制日志，当使用CREATE...SELECTorINSERT...SELECT时，并行插入被转换为普通插入。这样通过在备份时使用日志可以确保重新创建表的备份。请注意MySQL5.1值的二进制日志格式与以前版本的MySQL不同，因为复制改进了。参见6.5节，“不同MySQL版本之间的复制兼容性”。默认情况下，并不是每次写入时都将二进制日志与硬盘同步。因此如果操作系统或机器(不仅仅是MySQL服务器)崩溃，有可能二进制日志中最后的语句丢失了。要想防止这种情况，你可以使用sync_binlog全局变量(1是最安全的值，但也是最慢的)，使二进制日志在每N次二进制日志写入后与硬盘同步。参见5.3.3节，“服务器系统变量”。即使sync_binlog设置为1,出现崩溃时，也有可能表内容和二进制日志内容之间存在不一致性。例如，如果使用InnoDB表，MySQL服务器处理COMMIT语句，它将整个事务写入二进制日志并将事务提交到InnoDB中。如果在两次操作之间出现崩溃，重启时，事务被InnoDB回滚，但仍然存在二进制日志中。可以用--innodb-safe-binlog选项解决该问题，可以增加InnoDB表内容和二进制日志之间的一致性。(注释：在MySQL5.1中不需要--innodb-safe-binlog；由于引入了XA事务支持，该选项作废了）。该选项可以提供更大程度的安全，还应对MySQL服务器进行配置，使每个事务的二进制日志(sync_binlog=1)和(默认情况为真)InnoDB日志与硬盘同步。该选项的效果是崩溃后重启时，在滚回事务后，MySQL服务器知博网zhiblog.com务器保持与主服务器保持同步(不接收回滚的语句)。Linux专题从二进制日志剪切回滚的InnoDB事务。这样可以确保二进制日志反馈InnoDB表的确切数据等，并使从服请注意即使MySQL服务器更新其它存储引擎而不是InnoDB，也可以使用--innodb-safe-binlog。在InnoDB崩溃恢复时，只从二进制日志中删除影响InnoDB表的语句/事务。如果崩溃恢复时MySQL服务器发现二进制日志变短了(即至少缺少一个成功提交的InnoDB事务)，如果sync_binlog=1并且硬盘/文件系统的确能根据需要进行同步(有些不需要)则不会发生，则输出错误消息(\"二进制日志<名>比期望的要小\")。在这种情况下，二进制日志不准确，复制应从主服务器的数据快照开始。写入二进制日志文件和二进制日志索引文件的方法与写入MyISAM表相同。参见A.4.3节，“MySQL处理磁盘满的方式”。5.11.4.慢速查询日志用--log-slow-queries[=file_name]选项启动时，mysqld写一个包含所有执行时间超过long_query_time秒的SQL语句的日志文件。获得初使表锁定的时间不算作执行时间。如果没有给出file_name值，默认为主机名，后缀为-slow.log。如果给出了文件名，但不是绝对路径名，文件则写入数据目录。语句执行完并且所有锁释放后记入慢查询日志。记录顺序可以与执行顺序不相同。慢查询日志可以用来找到执行时间长的查询，可以用于优化。但是，检查又长又慢的查询日志会很困难。要想容易些，你可以使用mysqldumpslow命令获得日志中显示的查询摘要来处理慢查询日志。在MySQL5.1的慢查询日志中，不使用索引的慢查询同使用索引的查询一样记录。要想防止不使用索引的慢查询记入慢查询日志，使用--log-short-format选项。参见5.3.1节，“mysqld命令行选项”。在MySQL5.1中,通过--log-slow-admin-statements服务器选项，你可以请求将慢管理语句，例如OPTIMIZETABLE、ANALYZETABLE和ALTERTABLE写入慢查询日志。用查询缓存处理的查询不加到慢查询日志中，因为表有零行或一行而不能从索引中受益的查询也不写入慢查询日志。5.11.5.日志文件维护MySQL服务器可以创建各种不同的日志文件，从而可以很容易地看见所进行的操作。参见5.11节，“MySQL日志文件”。但是，你必须定期清理这些文件，确保日志不会占用太多的硬盘空间。当启用日志使用MySQL时，你可能想要不时地备份并删除旧的日志文件，并告诉MySQL开始记入新文件。参见5.9.1节，“数据库备份”。在Linux(Redhat)的安装上，你可为此使用mysql-log-rotate脚本。如果你从RPM分发安装MySQL，脚本应该自动被安装了。在其它系统上，你必须自己安装短脚本，你可从cron等入手处理日志文件。你可以通过mysqladminflush-logs或SQL语句FLUSHLOGS来强制MySQL开始使用新的日志文件。日志清空操作做下列事情：•如果使用标准日志(--log)或慢查询日志(--log-slow-queries)，关闭并重新打开日志文件。(默认为mysql.log和`hostname`-slow.log)。•如果使用更新日志(--log-update)或二进制日志(--log-bin)，关闭日志并且打开有更高序列号的新日志文件。•如果使用错误日志，如使用了--log-error选项启动mysqld，则以-old重命名旧日志并打开一个新的空日志；否则，关闭并打开原来的日志。如果你只使用更新日志，你只需要重新命名日志文件，然后在备份前清空日志。例如，你可以这样做：知博网zhiblog.comshell>cdmysql-data-directoryshell>mvmysql.logmysql.oldshell>mysqladminflush-logs然后做备份并删除“mysql.old”。Linux专题来源：http://blog.sina.com.cn/s/blog_4d22b9720100c5b6.html（到该博客阅读其他文章）使用MYSQLBINLOG来恢复数据今天在家里做了一下试验，终于搞明白了以前做复制的时候没有搞明白的问题。原来BINLOG就是一个记录SQL语句的过程，和普通的LOG一样。不过只是她是二进制存储，普通的是十进制存储罢了。1、配置文件里要写的东西：[mysqld]log-bin=yueliangdao_binglog(名字可以改成自己的，如果不改名字的话，默认是以主机名字命名)重新启动MSYQL服务。二进制文件里面的东西显示的就是执行所有语句的详细记录，当然一些语句不被记录在内，要了解详细的，见手册页。2、查看自己的BINLOG的名字是什么。showbinlogevents;queryresult(1records)Log_namePosEvent_typeServer_idEnd_log_pos106InfoServerver:5.1.22-rc-community-log,Binlogver:43、我做了几次操作后，它就记录了下来。又一次showbinlogevents的结果。queryresult(4records)Log_namePosEvent_typeServer_iEnd_log_pods106InfoServerver:5.1.22-rc-community-log,Binlogver:4yueliangdao_binglog.000010Intvar0161254use`test`;createtablea1(idintnotnullauto_incrementprimarykey,strvarchar(1000))1134INSERT_ID=1yueliangdao_binglog.0000401Format_des1cyueliangdao_binglog.0000401Format_des1cyueliangdao_binglog.000013Query014知博网zhiblog.comLinux专题engine=myisamyueliangdao_binglog.000025Query0141330use`test`;insertintoa1(str)values('Iloveyou'),('Youloveme')yueliangdao_binglog.000033Query0101485use`test`;droptablea14、用mysqlbinlog工具来显示记录的二进制结果，然后导入到文本文件，为了以后的恢复。详细过程如下：D:\\LAMP\\MYSQL5\\data>mysqlbinlog--start-position=4--stop-position=106yueliangdao_binglog.000001>c:\\\est1.txttest1.txt的文件内容：/*!40019SET@@session.max_insert_delayed_threads=0*/;/*!50003SET@OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;DELIMITER/*!*/;#at4#712216:9:18serverid1end_log_pos106startup#Warning:thisbinlogwasnotclosedproperly.Mostprobablymysqldcrashedwritingit.ROLLBACK/*!*/;DELIMITER;#EndoflogfileROLLBACK/*addedbymysqlbinlog*/;/*!50003SETCOMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;Start:binlogv4,serverv5.1.22-rc-community-logcreated712216:9:18at第二行的记录：D:\\LAMP\\MYSQL5\\data>mysqlbinlog--start-position=106--stop-position=134yueliangdao_binglog.000001>c:\\\est1.txttest1.txt内容如下：/*!40019SET@@session.max_insert_delayed_threads=0*/;/*!50003SET@OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;DELIMITER/*!*/;#at106#712216:22:36serverid1end_log_pos134SETINSERT_ID=1/*!*/;DELIMITER;#EndoflogfileROLLBACK/*addedbymysqlbinlog*/;/*!50003SETCOMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;Intvar第三行记录：D:\\LAMP\\MYSQL5\\data>mysqlbinlog--start-position=134--stop-position=254yueliangdao_binglog.000001>c:\\\est1.txt内容：/*!40019SET@@session.max_insert_delayed_threads=0*/;/*!50003SET@OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;DELIMITER/*!*/;#at134#712216:55:31serverid1end_log_pos254usetest/*!*/;SETTIMESTAMP=1196585731/*!*/;SET@@session.foreign_key_checks=1,@@session.sql_auto_is_null=1,@@session.unique_checks=1/*!*/;SET@@session.sql_mode=1344274432/*!*/;Querythread_id=1exec_time=0error_code=0知博网zhiblog.com/*!\\Cutf8*//*!*/;Linux专题SET@@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;createtablea1(idintnotnullauto_incrementprimarykey,strvarchar(1000))engine=myisam/*!*/;DELIMITER;#EndoflogfileROLLBACK/*addedbymysqlbinlog*/;/*!50003SETCOMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;/*!40019SET@@session.max_insert_delayed_threads=0*/;第四行的记录：D:\\LAMP\\MYSQL5\\data>mysqlbinlog--start-position=254--stop-position=330yueliangdao_binglog.000001>c:\\\est1.txt/*!50003SET@OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;DELIMITER/*!*/;#at254#712216:22:36serverid1end_log_pos330usetest/*!*/;SETTIMESTAMP=1196583756/*!*/;SET@@session.foreign_key_checks=1,@@session.sql_auto_is_null=1,@@session.unique_checks=1/*!*/;SET@@session.sql_mode=1344274432/*!*/;/*!\\Cutf8*//*!*/;SET@@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;use`test`;insertintoa1(str)values('Iloveyou'),('Youloveme')/*!*/;DELIMITER;#EndoflogfileROLLBACK/*addedbymysqlbinlog*/;/*!50003SETCOMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;Querythread_id=1exec_time=0error_code=05、查看这些东西是为了恢复数据，而不是为了好玩。所以我们最中还是为了要导入结果到MYSQL中。D:\\LAMP\\MYSQL5\\data>mysqlbinlog--start-position=134--stop-position=330yueliangdao_binglog.000001|mysql-uroot–p[管道命令，登录mysql服务器，将日志内容传入，实现恢复]或者D:\\LAMP\\MYSQL5\\data>mysqlbinlog--start-position=134--stop-position=330yueliangdao_binglog.000001>test1.txt进入MYSQL导入mysql>sourcec:\\\est1.txt[linux命令，sourceFileName作用:在当前bash环境下读取并执行FileName中的命令。注：该命令通常用命令“.”来替代。]QueryOK,0rowsaffectedQueryOK,0rowsaffectedDatabasechangedQueryOK,0rowsaffectedQueryOK,0rowsaffectedQueryOK,0rowsaffectedCharsetchangedQueryOK,0rowsaffectedQueryOK,0rowsaffectedQueryOK,0rowsaffectedQueryOK,0rowsaffected6、查看数据：mysql>showtables;(0.00sec)(0.00sec)(0.00sec)(0.00sec)(0.00sec)(0.00(0.03(0.00(0.00sec)sec)sec)sec)知博网zhiblog.com+----------------+|Tables_in_test|+----------------+|a1|+----------------+1rowinset(0.01sec)mysql>select*froma1;+----+-------------+|id|str|+----+-------------+|1|Iloveyou||2|Youloveme|+----+-------------+2rowsinset(0.00sec)Linux专题问：我从本地新建了一个和服务器相同的表，但是忘记备份服务器的表，结果，上传到服务器后就覆盖了原来的表，结果里面的信息都丢了，有办法恢复吗？答：如果你开启了二进制日志，当然可以恢复。来源：http://blog.chinaunix.net/u/29134/showart_434296.html使用mysqlbinlog恢复数据mysqlbinlog工具的使用,大家可以看MySQL的帮助手册。里面有详细的用，在这个例子中，重点是--start-position参数和--stop-position参数的使用。•--start-position=N从二进制日志中第1个位置等于N参量时的事件开始读。•--stop-position=N从二进制日志中第1个位置等于和大于N参量时的事件起停止读。1、OK，现在开始，要启动二进制日志记录，要先在my.cnf/my.ini文件的mysqld里添加log-bin=日志名在这里，偶是的设置是log-bin=liangck然后再启动mysql服务，因为偶是用windows系统，所以执行netstartmysql命令即可。2、然后在一测试数据库里，创建一个表，并添加记录。SQLcodemysql>createtabletest(idintauto_incrementnotnullprimarykey,valint,datavarchar(20));mysql>insertintotest(val,data)values(10,'liang');QueryOK,1rowaffected(0.03sec)mysql>insertintotest(val,data)values(20,'jia');QueryOK,1rowaffected(0.08sec)mysql>insertintotest(val,data)values(30,'hui');QueryOK,1rowaffected(0.03sec)mysql>flushlogs;--产生第二个日志文件QueryOK,0rowsaffected(0.09sec)知博网zhiblog.commysql>insertintotest(val,data)values(40,'aaa');QueryOK,1rowaffected(0.05sec)mysql>insertintotest(val,data)values(50,'bbb');QueryOK,1rowaffected(0.03sec)mysql>insertintotest(val,data)values(60,'ccc');QueryOK,1rowaffected(0.03sec)mysql>deletefromtestwhereidbetween4and5;QueryOK,2rowsaffected(0.05sec)mysql>insertintotest(val,data)values(70,'ddd');QueryOK,1rowaffected(0.03sec)mysql>flushlogs;--产生第三个文件文件--删除记录Linux专题QueryOK,0rowsaffected(0.11sec)mysql>insertintotest(val,data)values(80,'dddd');QueryOK,1rowaffected(0.05sec)mysql>insertintotest(val,data)values(90,'eeee');QueryOK,1rowaffected(0.03sec)mysql>droptabletest;--删除表QueryOK,0rowaffected(0.05sec)――――――――――――――――――――――――――――――――――3、OK，现在测试数据已经建好了，要求是什么呢？就是将test表的数据全部恢复出来。先用mysqlbinlog工具将日志文件生成txt文件出来分析。F:\\ProgramFiles\\MySQL_Data\\data\\log>mysqlbinlogliangck.000001>G:\\001.txtF:\\ProgramFiles\\MySQL_Data\\data\\log>mysqlbinlogliangck.000002>G:\\002.txtF:\\ProgramFiles\\MySQL_Data\\data\\log>mysqlbinlogliangck.000003>G:\\003.txt通过这三个命令，可以在G盘下生成3个文件，里面分别记录了日志文件的内容，也就是用户操作的步骤。因为我们需要重做第一个日志文件的所有操作，所以这里只需要将第一个日志文件全恢复就行了。F:\\ProgramFiles\\MySQL_Data\\data\\log>mysqlbinlogliangck.000001|mysql-uroot–pOk,接着，我们需要分析的是第二个日志文件。为什么要分析它呢，因为它中途执行了一个操作是DELETE，因为我们要做的是恢复全部数据，也就是我们不希望去重做这个语句。所以在这里我们要想办法去绕开它。我们先打开002.txt文件来分析一下。在这个文件中，我们可以看到DELETE的操作的起始位置是875，终止位置是1008.那么我们只要重做第二个日志文件的开头到875的操作，然后再从1008到末尾的操作，我们就可以把数据给恢复回来，而不会DELETE数据。所以执行两个命令：F:\\ProgramFiles\\MySQL_Data\\data\\log>mysqlbinlogliangck.000002--stop-pos=875|mysql-uroot-pF:\\ProgramFiles\\MySQL_Data\\data\\log>liangck.000002--start-pos=1008|mysql-uroot-pmytestOK,现在第二个日志文件的数据恢复好了。知博网zhiblog.com第三个日志文件也是同理，只要找到DROPTABLE的位置，就可以了。Linux专题F:\\Prog..\\MySQL_Data\\data\\log>mysqlbinlogliangck.000003--stop-pos=574|mysql-uroot–p4、现在我们再查一下数据看看:SQLcodemysql>select*fromtest;+----+------+-------+|id|val|data|+----+------+-------+|1|10|liang||2|20|jia||3|30|hui||4|40|aaa||5|50|bbb||6|60|ccc||7|70|ddd||8|80|dddd||9|90|eeee|+----+------+-------+9rowsinset(0.00sec)可以看到，全部数据都回来了。来源：http://bbs.zbitedu.com/thread-21259-1-1.htmlmysqlbinlog怎么将数据库恢复到指定的时间？来源：http://www.javaeye.com/problems/6634