MYSQL启用日志，查看日志，利用mysqlbinlog工具恢复MySQL数据库 - Dream Idears - ITeye技术网站
博客分类：
MYSQL启用日志[root@jianshe99]# whereis my.ini[root@jianshe99]# vi /f[mysqld]datadir=/var/lib/mysqlsocket=/var/lib/mysql/mysql.sockuser=mysql# Default to using old password format for compatibility with mysql 3.x# clients (those using the mysqlclient10 compatibility package).old_passwords=1[mysqld_safe]log-error=/var/log/mysqld.loglong_query_time =1log-slow-queries=slowqueris.loglog-queries-not-using-indexes = nouseindex.loglog=mylog.logpid-file=/var/run/mysqld/mysqld.pid--------------------------------------------------------查看日志
是否启用了日志mysql&show variables like 'log_bin';
怎样知道当前的日志mysql&
看二进制日志文件用mysqlbinlogshell&mysqlbinlog mail-bin.000001或者shell&mysqlbinlog mail-bin.000001 | tail
Windows 下用类似的命令。
mysql有以下几种日志： 错误日志： -log-err 查询日志： -log 慢查询日志: -log-slow-queries 更新日志: -log-update 二进制日志： -log-bin 在mysql的安装目录下，打开my.ini,在后面加上上面的参数，保存后重启mysql服务就行了。LAST_UPDATED2-------------------------------------------------------------如果MySQL服务器启用了二进制日志，你可以使用mysqlbinlog工具来恢复从指定的时间点开始 (例如，从你最后一次备份)直到现在或另一个指定的时间点的数据。关于启用二进制日志的信息，参见5.11.3节，“二进制日志”。对于 mysqlbinlog的详细信息，参见mysql手册8.6节，“mysqlbinlog：用于处理二进制日志文件的实用工具”。
要想从二进制日志恢复数据，你需要知道当前二进制日志文件的路径和文件名。一般可以从选项文件(即my.cnf or my.ini，取决于你的系统)中找到路径。如果未包含在选项文件中，当服务器启动时，可以在命令行中以选项的形式给出。启用二进制日志的选项为-- log-bin。要想确定当前的二进制日志文件的文件名，输入下面的MySQL语句：
SHOW BINLOG EVENTS G
你还可以从命令行输入下面的内容：
mysql --user=root -pmy_pwd -e 'SHOW BINLOG EVENTS G'
将密码my_pwd替换为服务器的root密码。
1. 指定恢复时间
对于MySQL 4.1.4，可以在mysqlbinlog语句中通过--start-date和--stop-date选项指定DATETIME格式的起止时间。举例说明，假设在今天上午10:00(今天是日)，执行SQL语句来删除一个大表。要想恢复表和数据，你可以恢复前晚上的备份，并输入：
mysqlbinlog --stop-date=" 9:59:59" /var/log/mysql/bin.123456| mysql -u root -pmypwd
该命令将恢复截止到在--stop-date选项中以DATETIME格式给出的日期和时间的所有数据。如果你没有检测到几个小时后输入的错误的SQL语句，可能你想要恢复后面发生的活动。根据这些，你可以用起使日期和时间再次运行mysqlbinlog：
mysqlbinlog --start-date=" 10:01:00" /var/log/mysql/bin.123456| mysql -u root -pmypwd
在该行中，从上午10:01登录的SQL语句将运行。组合执行前夜的转储文件和mysqlbinlog的两行可以将所有数据恢复到上午10:00前一秒钟。你应检查日志以确保时间确切。下一节介绍如何实现。
2. 指定恢复位置
也可以不指定日期和时间，而使用mysqlbinlog的选项--start-position和--stop-position来指定日志位置。它们的作用与起止日选项相同，不同的是给出了从日志起的位置号。使用日志位置是更准确的恢复方法，特别是当由于破坏性SQL语句同时发生许多事务的时候。要想确定位置号，可以运行mysqlbinlog寻找执行了不期望的事务的时间范围，但应将结果重新指向文本文件以便进行检查。操作方法为：
mysqlbinlog --start-date=" 9:55:00" --stop-date=" 10: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 -u root -pmypwdmysqlbinlog --start-position="368315" /var/log/mysql/bin.123456| mysql -u root -pmypwd
上面的第1行将恢复到停止位置为止的所有事务。下一行将恢复从给定的起始位置直到二进制日志结束的所有事务。因为mysqlbinlog的输出包括每个SQL语句记录之前的SET TIMESTAMP语句，恢复的数据和相关MySQL日志将反应事务执行的原时间。
浏览: 148809 次
你这个程序一存在线程的时间片相互抢占的问题，运行时间长了很可能 ...
我觉得话应该这么说：引用TestThread tt = new ...
调用TelephonyManager的隐藏API是先参考Fra ...Mysql无Binlog数据恢复_图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
Mysql无Binlog数据恢复
上传于|0|0|文档简介
&&mysql数据恢复,无Binlog数据恢复,delete数据恢复
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩2页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢无全量备份、未开启binlog日志，利用percona工具恢复delete的数据 - 推酷
无全量备份、未开启binlog日志，利用percona工具恢复delete的数据
今天，利用Percona&Data&Recovery&Tool&for&InnoDB工具（仅支持InnoDB，MyISAM不支持），可以找回被删除的数据。
原理：在InnoDB引擎，delete删除操作，不是真正的删除物理文件上的行，而是增加一个删除的标记，我们都用过WORD吧？在修改字体的时候，有一个删除线的标记，如《MySQL&管理之道》，该工具利用这个特性，找回那些标注了删除线的数据，并存入到一个文本里，然后通过load&data命令，批量插入到表里。
注：truncate不能恢复（truncate是直接清空数据行，并不是添加删除标记，你可以通过查看物理文件，执行了truncate操作，ibd文件变小，而执行了delete操作，ibd文件还跟之前的一样大），drop不能恢复（数据文件都没了，还怎么恢复？）。
一、安装Percona&Data&Recovery&Tool&for&InnoDB工具
# cd percona-data-recovery-tool-for-innodb-0.5/mysql-source
# ./configure
二、全表删除sbtest表
1、提取ibd物理文件，按照每页16K，单独存放。
# cd percona-data-recovery-tool-for-innodb-0.5/
# ./page_parser -5 -f /usr/local/mysql-5.5.37/data/test/sbtest.ibd
会在当前目录生成一个pages-目录（后面的数字是变化的，在你的机器上会跟我的不同）
在FIL_PAGE_INDEX目录下面，会生成主键和索引，数据最小的是主键，后面依次是每个列的索引
在这里，0-28是sbtest表的主键(id)，0-29是sbtest表的索引(k)。记住这个目录数字，后面我们需要通过这个目录恢复数据。
2、生成表结构
# cd percona-data-recovery-tool-for-innodb-0.5/
# ./create_defs.pl --host localhost --port 3306 --user root --password 123456 --db test --table sbtest & include/table_defs.h
--&host&主机地址
--&port&端口
--&user&用户名
--&password&密码
--&db&数据库名
--&table&表名
3、再次执行make编译命令
# cd percona-data-recovery-tool-for-innodb-0.5/
4、恢复删除的数据
# cd percona-data-recovery-tool-for-innodb-0.5/
# ./constraints_parser -D -5 -f pages-/FIL_PAGE_INDEX/0-28/ & /tmp/sbtest.txt
D&恢复删除的行-5&表的文件格式，默认是Compact
（不清楚的朋友，可以用show&table&status命令查看）
-f&指定生成sbtest表的主键目录
执行完毕，如下图：
会自动生成一个load&data&infile命令，请把这个复制下来，一会我们要导入数据。
在/tmp目录下，会生成sbtest.txt，我们就要用这个文件做恢复。
5、导入到表里
LOAD DATA INFILE '/tmp/sbtest.txt' REPLACE INTO TABLE `sbtest` FIELDS TERMINATED BY '\t' OPTIONALLY ENCLOSED BY '&' LINES STARTING BY 'sbtest\t' (id, k, c, pad);
通过上述方法，顺利的完成了delete数据恢复。在数据被删除后，切记要备份ibd数据文件，一定不要覆盖，否则都是不能完成修复的。目前该工具不支持字符串set类型。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致load data 方式导入的数据不可以用binlog日志进行恢复，因为binlog里面不产生insert sql语句。 分享 - 谷普下载load data 方式导入的数据不可以用binlog日志进行恢复，因为binlog里面不产生insert sql语句。点击复制内容
QQ群有人问起这个: & &用
的时候，在文件中记载的不是 ,这样的话，，如果用
，当需要数据库的时候 &就不行了load data local infile '/root/table.txt' into table test.生成binlog 然后用mysqlbinlog解析binlog，再more查看如下：# at 147405#:15:02 server id 1 &end_log_pos 147710 & & & &Query & thread_id=97960 exec_time=0 & & error_code=0use test/*!*/;SET TIMESTAMP=/*!*/;SET @@session.sql_mode=0/*!*/;/*!C utf8 *//*!*/;SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;create table `test`.`table`( & `c1` varchar(20) , & `c2` varchar(20) , & `c3` varchar(20) , & `c4` varchar(20) , & `c5` varchar(20) , & `c6` varchar(20) , & `c7` varchar(20) , & `c8` varchar(20) , & `c9` varchar(20) )/*!*/;# at 147710#:17:14 server id 1 &end_log_pos 147783 & & & &Query & thread_id=98119 exec_time=2 & & error_code=0SET TIMESTAMP=/*!*/;SET @@session.sql_mode=4194304/*!*/;BEGIN/*!*/;# at 147783#:17:14 server id 1 &end_log_pos 164190#Begin_load_query: file_id: 1 &block_len: 16384# at 164190#:17:14 server id 1 &end_log_pos 180597#Append_block: file_id: 1 &block_len: 16384# at 180597#:17:14 server id 1 &end_log_pos 197004#Append_block: file_id: 1 &block_len: 16384# at 197004#:17:14 server id 1 &end_log_pos 213411#Append_block: file_id: 1 &block_len: 16384# at 213411#:17:14 server id 1 &end_log_pos 229818#Append_block: file_id: 1 &block_len: 16384# at 229818#:17:14 server id 1 &end_log_pos 246225#Append_block: file_id: 1 &block_len: 16384# at 246225#:17:14 server id 1 &end_log_pos 262632#Append_block: file_id: 1 &block_len: 16384# at 262632#:17:14 server id 1 &end_log_pos 279039#Append_block: file_id: 1 &block_len: 16384# at 279039#:17:14 server id 1 &end_log_pos 295446#Append_block: file_id: 1 &block_len: 16384# at 295446#:17:14 server id 1 &end_log_pos 311853#Append_block: file_id: 1 &block_len: 16384# at 311853#:17:14 server id 1 &end_log_pos 328260#Append_block: file_id: 1 &block_len: 16384# at 328260#:17:14 server id 1 &end_log_pos 344667#Append_block: file_id: 1 &block_len: 16384# at 344667#:17:14 server id 1 &end_log_pos 361074#Append_block: file_id: 1 &block_len: 16384# at 361074#:17:14 server id 1 &end_log_pos 377481#Append_block: file_id: 1 &block_len: 16384# at 377481#:17:14 server id 1 &end_log_pos 393888#Append_block: file_id: 1 &block_len: 16384# at 393888#:17:14 server id 1 &end_log_pos 410295#Append_block: file_id: 1 &block_len: 16384# at 410295#:17:14 server id 1 &end_log_pos 426702#Append_block: file_id: 1 &block_len: 16384# at 426702#:17:14 server id 1 &end_log_pos 443109#Append_block: file_id: 1 &block_len: 16384# at 443109#:17:14 server id 1 &end_log_pos 459516#Append_block: file_id: 1 &block_len: 16384# at 459516#:17:14 server id 1 &end_log_pos 475923#Append_block: file_id: 1 &block_len: 16384# at 475923#:17:14 server id 1 &end_log_pos 492330#Append_block: file_id: 1 &block_len: 16384# at 492330#:17:14 server id 1 &end_log_pos 508737#Append_block: file_id: 1 &block_len: 16384# at 508737#:17:14 server id 1 &end_log_pos 525144#Append_block: file_id: 1 &block_len: 16384# at 525144#:17:14 server id 1 &end_log_pos 541551#Append_block: file_id: 1 &block_len: 16384# at 541551#:17:14 server id 1 &end_log_pos 557958#Append_block: file_id: 1 &block_len: 16384# at 557958#:17:14 server id 1 &end_log_pos 574365#Append_block: file_id: 1 &block_len: 16384# at 574365#:17:14 server id 1 &end_log_pos 590772#Append_block: file_id: 1 &block_len: 16384# at 590772#:17:14 server id 1 &end_log_pos 607179#Append_block: file_id: 1 &block_len: 16384# at 607179#:17:14 server id 1 &end_log_pos 623586#Append_block: file_id: 1 &block_len: 16384# at 623586#:17:14 server id 1 &end_log_pos 639993#Append_block: file_id: 1 &block_len: 16384# at 639993#:17:14 server id 1 &end_log_pos 656400#Append_block: file_id: 1 &block_len: 16384# at 656400#:17:14 server id 1 &end_log_pos 672807#Append_block: file_id: 1 &block_len: 16384# at 672807#:17:14 server id 1 &end_log_pos 689214#Append_block: file_id: 1 &block_len: 16384# at 689214#:17:14 server id 1 &end_log_pos 705621#Append_block: file_id: 1 &block_len: 16384# at 705621#:17:14 server id 1 &end_log_pos 722028#Append_block: file_id: 1 &block_len: 16384# at 722028#:17:14 server id 1 &end_log_pos 738435#Append_block: file_id: 1 &block_len: 16384# at 738435#:17:14 server id 1 &end_log_pos 754842#Append_block: file_id: 1 &block_len: 16384# at 754842#:17:14 server id 1 &end_log_pos 771249#Append_block: file_id: 1 &block_len: 16384# at 771249#:17:14 server id 1 &end_log_pos 787656#Append_block: file_id: 1 &block_len: 16384# at 787656#:17:14 server id 1 &end_log_pos 804063#Append_block: file_id: 1 &block_len: 16384# at 804063#:17:14 server id 1 &end_log_pos 820470#Append_block: file_id: 1 &block_len: 16384# at 820470#:17:14 server id 1 &end_log_pos 836877#Append_block: file_id: 1 &block_len: 16384# at 836877#:17:14 server id 1 &end_log_pos 853284 &
#Append_block: file_id: 1 &block_len: 16384# at 853284#:17:14 server id 1 &end_log_pos 869691#Append_block: file_id: 1 &block_len: 16384# at 869691#:17:14 server id 1 &end_log_pos 886098#Append_block: file_id: 1 &block_len: 16384# at 886098#:17:14 server id 1 &end_log_pos 902505#Append_block: file_id: 1 &block_len: 16384# at 902505#:17:14 server id 1 &end_log_pos 918912#Append_block: file_id: 1 &block_len: 16384# at 918912#:17:14 server id 1 &end_log_pos 935319#Append_block: file_id: 1 &block_len: 16384# at 935319#:17:14 server id 1 &end_log_pos 951726#Append_block: file_id: 1 &block_len: 16384# at 951726#:17:14 server id 1 &end_log_pos 968133#Append_block: file_id: 1 &block_len: 16384# at 968133#:17:14 server id 1 &end_log_pos 984540#Append_block: file_id: 1 &block_len: 16384# at 984540#:17:14 server id 1 &end_log_pos 1000947#Append_block: file_id: 1 &block_len: 16384# at 1000947#:17:14 server id 1 &end_log_pos 1017354#Append_block: file_id: 1 &block_len: 16384# at 1017354#:17:14 server id 1 &end_log_pos 1033761#Append_block: file_id: 1 &block_len: 16384# at 1033761#:17:14 server id 1 &end_log_pos 1050168#Append_block: file_id: 1 &block_len: 16384# at 1050168#:17:14 server id 1 &end_log_pos 1066575#Append_block: file_id: 1 &block_len: 16384# at 1066575#:17:14 server id 1 &end_log_pos 1082982#Append_block: file_id: 1 &block_len: 16384# at 1082982#:17:14 server id 1 &end_log_pos 1099389#Append_block: file_id: 1 &block_len: 16384# at 1099389#:17:14 server id 1 &end_log_pos 1115796#Append_block: file_id: 1 &block_len: 16384# at 1115796#:17:14 server id 1 &end_log_pos 1132203#Append_block: file_id: 1 &block_len: 16384# at 1132203#:17:14 server id 1 &end_log_pos 1148610#Append_block: file_id: 1 &block_len: 16384# at 1148610#:17:14 server id 1 &end_log_pos 1165017#Append_block: file_id: 1 &block_len: 16384# at 1165017#:17:14 server id 1 &end_log_pos 1181424#Append_block: file_id: 1 &block_len: 16384# at 1181424#:17:14 server id 1 &end_log_pos 1197831#Append_block: file_id: 1 &block_len: 16384# at 1197831#:17:14 server id 1 &end_log_pos 1214238#Append_block: file_id: 1 &block_len: 16384# at 1214238#:17:14 server id 1 &end_log_pos 1230645#Append_block: file_id: 1 &block_len: 16384# at 1230645#:17:14 server id 1 &end_log_pos 1247052#Append_block: file_id: 1 &block_len: 16384# at 1247052#:17:14 server id 1 &end_log_pos 1263459#Append_block: file_id: 1 &block_len: 16384# at 1263459#:17:14 server id 1 &end_log_pos 1279866#Append_block: file_id: 1 &block_len: 16384# at 1279866#:17:14 server id 1 &end_log_pos 1296273#Append_block: file_id: 1 &block_len: 16384# at 1296273#:17:14 server id 1 &end_log_pos 1312680#Append_block: file_id: 1 &block_len: 16384# at 1312680#:17:14 server id 1 &end_log_pos 1329087#Append_block: file_id: 1 &block_len: 16384# at 1329087#:17:14 server id 1 &end_log_pos 1345494.........#Append_block: file_id: 1 &block_len: 16384# at 4298754#:17:14 server id 1 &end_log_pos 4315161#Append_block: file_id: 1 &block_len: 16384# at 4315161#:17:14 server id 1 &end_log_pos 4331568#Append_block: file_id: 1 &block_len: 16384# at 4331568#:17:14 server id 1 &end_log_pos 4347975#Append_block: file_id: 1 &block_len: 16384# at 4347975#:17:14 server id 1 &end_log_pos 4364382#Append_block: file_id: 1 &block_len: 16384# at 4364382#:17:14 server id 1 &end_log_pos 4380789#Append_block: file_id: 1 &block_len: 16384# at 4380789#:17:14 server id 1 &end_log_pos 4397196#Append_block: file_id: 1 &block_len: 16384# at 4397196#:17:14 server id 1 &end_log_pos 4413603#Append_block: file_id: 1 &block_len: 16384# at 4413603#:17:14 server id 1 &end_log_pos 4430010#Append_block: file_id: 1 &block_len: 16384# at 4430010#:17:14 server id 1 &end_log_pos 4446417#Append_block: file_id: 1 &block_len: 16384# at 4446417#:17:14 server id 1 &end_log_pos 4462824#Append_block: file_id: 1 &block_len: 16384# at 4462824#:17:14 server id 1 &end_log_pos 4479231#Append_block: file_id: 1 &block_len: 16384# at 4479231#:17:14 server id 1 &end_log_pos 4495638#Append_block: file_id: 1 &block_len: 16384# at 4495638#:17:14 server id 1 &end_log_pos 4512045#Append_block: file_id: 1 &block_len: 16384# at 4512045#:17:14 server id 1 &end_log_pos 4528452#Append_block: file_id: 1 &block_len: 16384# at 4528452#:17:14 server id 1 &end_log_pos 4544859#Append_block: file_id: 1 &block_len: 16384# at 4544859#:17:14 server id 1 &end_log_pos 4561266#Append_block: file_id: 1 &block_len: 16384# at 4561266#:17:14 server id 1 &end_log_pos 4577673#Append_block: file_id: 1 &block_len: 16384# at 4577673#:17:14 server id 1 &end_log_pos 4594080#Append_block: file_id: 1 &block_len: 16384# at 4594080#:17:14 server id 1 &end_log_pos 4610487#Append_block: file_id: 1 &block_len: 16384# at 4610487#:17:14 server id 1 &end_log_pos 4626894#Append_block: file_id: 1 &block_len: 16384# at 4626894#:17:14 server id 1 &end_log_pos 4643301#Append_block: file_id: 1 &block_len: 16384# at 4643301#:17:14 server id 1 &end_log_pos 4659708#Append_block: file_id: 1 &block_len: 16384# at 4659708#:17:14 server id 1 &end_log_pos 4676115#Append_block: file_id: 1 &block_len: 16384# at 4676115#:17:14 server id 1 &end_log_pos 4692522#Append_block: file_id: 1 &block_len: 16384# at 4692522#:17:14 server id 1 &end_log_pos 4708929#Append_block: file_id: 1 &block_len: 16384# at 4708929#:17:14 server id 1 &end_log_pos 4725336#Append_block: file_id: 1 &block_len: 16384# at 4725336#:17:14 server id 1 &end_log_pos 4735417#Append_block: file_id: 1 &block_len: 10058# at 4735417#:17:14 server id 1 &end_log_pos 4735701 & & & Execute_load_query & & &thread_id=98119 exec_time=2 & & error_code=0SET TIMESTAMP=/*!*/;LOAD DATA LOCAL INFILE '/tmp/SQL_LOAD_MB-1-0' INTO TABLE `table` FIELDS TERMINATED BY 't' ENCLOSED BY '' ESCAPED BY '' LINES TERMINATED BY 'n' (`c1`, `c2`, `c3`, `c4`, `c5`, `c6`, `c7`, `c8`, `c9`)/*!*/;# file_id: 1# at 4735701#:17:14 server id 1 &end_log_pos 4735728 & & & Xid = 297745COMMIT/*!*/;DELIMITER ;# End of log fileROLLBACK /* added by mysqlbinlog */;/*!50003 SET _COMPLETION_TYPE*/;
确实没有之类的sql，当用binlog日志恢复的时候，会报错的，所以在生产环境上面，最好不要使用load data的数据导入。以免需要及时恢复数据的时候发生异常。-- 察看binlog事件,会看到最后的load data local infile纪录.mysql& show binlog events in "mysql-bin.000001";
| mysql-bin.000001 | 4708929 | Append_block
4725336 | ;file_id=1;block_len=16384
| mysql-bin.000001 | 4725336 | Append_block
4735417 | ;file_id=1;block_len=10058
| mysql-bin.000001 | 4735417 | Execute_load_query |
4735701 | use `test`; LOAD DATA LOCAL INFILE '/root/table.txt' IGNORE INTO TABLE `table` FIELDS TERMINATED BY 't' ENCLOSED BY '' ESCAPED BY '' LINES TERMINATED BY 'n' (`c1`, `c2`, `c3`, `c4`, `c5`, `c6`, `c7`, `c8`, `c9`) ;file_id=1
| mysql-bin.000001 | 4735701 | Xid
4735728 | COMMIT /* xid=297745 */- 再察看从库数据也都同步复制过去了,再看从库的binlog日志# at #:15:02 server id 1 &end_log_pos
& & &Query & thread_id=97960 exec_time= & &error_code=0use test/*!*/;SET TIMESTAMP=/*!*/;SET @@session.sql_mode=0/*!*/;/*!C utf8 *//*!*/;SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;create table `test`.`table`( & `c1` varchar(20) , & `c2` varchar(20) , & `c3` varchar(20) , & `c4` varchar(20) , & `c5` varchar(20) , & `c6` varchar(20) , & `c7` varchar(20) , & `c8` varchar(20) , & `c9` varchar(20) )/*!*/;# at #:17:14 server id 1 &end_log_pos
& & &Query & thread_id=98119 exec_time=4 & & error_code=0SET TIMESTAMP=/*!*/;SET @@session.sql_mode=4194304/*!*/;BEGIN/*!*/;# at #:17:14 server id 1 &end_log_pos #Begin_load_query: file_id: 1 &block_len: 2097152# at #:17:14 server id 1 &end_log_pos #Append_block: file_id: 1 &block_len: 2097152# at #:17:14 server id 1 &end_log_pos #Append_block: file_id: 1 &block_len: 386890# at #:17:14 server id 1 &end_log_pos
& & &Execute_load_query & & &thread_id=98119 exec_time=4 & & error_code=0SET TIMESTAMP=/*!*/;LOAD DATA LOCAL INFILE '/tmp/SQL_LOAD_MB-1-0' INTO TABLE `table` FIELDS TERMINATED BY 't' ENCLOSED BY '' ESCAPED BY '' LINES TERMINATED BY 'n' (`c1`, `c2`, `c3`, `c4`, `c5`, `c6`, `c7`, `c8`, `c9`)/*!*/;# file_id: 1# at #:17:14 server id 1 &end_log_pos
& & &Xid = COMMIT/*!*/;-- 再去主库从库上面的tmp察看临时文件存在情况,果然看到SQL_LOAD_MB-1-0文件存在.[ tmp]# ll -t /tmp/ |moretotal 2212772-rw-r----- &1 root & & root & & & 4581194 Jul 18 11:46 SQL_LOAD_MB-1-0疑惑之一：不过我看到binlog有这么一句，LOAD DATA LOCAL INFILE '/tmp/SQL_LOAD_MB-1-0' INTO TABLE `table` FIELDS TERMINATED BY 't' ENCLOSED BY '' ESCAPED BY '' LINES TERMINATED BY 'n' (`c1`, `c2`, `c3`, `c4`, `c5`, `c6`, `c7`, `c8`, `c9`)如果'/tmp/SQL_LOAD_MB-1-0'文件存在的话，是否可以从binlog进行数据恢复呢？
来源：谷普下载