mysql load 记录日志_load data方式导入的数据不可以用binlog日志进行恢复，因为binlo_MySQL...

最新推荐文章于 2025-01-13 00:03:29 发布
原创 最新推荐文章于 2025-01-13 00:03:29 发布 · 1k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mysql load 记录日志

MySQL中的Load Data命令导入的数据在binlog中不会以INSERT语句形式记录，导致无法直接通过binlog恢复。文章通过解析binlog日志，展示了Load Data导入过程中的详细事件，强调在生产环境中避免依赖binlog恢复时使用此方法。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

bitsCN.com

load data方式导入的数据不可以用binlog日志进行恢复，因为binlog里面不产生insert sql语句

QQ群里面有人问起这个问题: 用load data 导入数据的时候，在binlog文件中记录的不是insert 语句,这样的话，如果用load data 导入数据，当需要恢复数据库的时候 binlog恢复就不行了

load data local infile '/root/table.txt' into table test.table ;

生成binlog 日志

然后用mysqlbinlog解析binlog日志，再more查看如下：

# at 147405

#130718 3:15:02 server id 1 end_log_pos 147710 Query thread_id=97960 exec_time=0 error_code=0

use test/*!*/;

SET TIMESTAMP=1374117302/*!*/;

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

#130718 3:17:14 server id 1 end_log_pos 147783 Query thread_id=98119 exec_time=2 error_code=0

SET TIMESTAMP=1374117434/*!*/;

SET @@session.sql_mode=4194304/*!*/;

BEGIN

/*!*/;

# at 147783

#130718 3:17:14 server id 1 end_log_pos 164190

#Begin_load_query: file_id: 1 block_len: 16384

# at 164190

#130718 3:17:14 server id 1 end_log_pos 180597

#Append_block: file_id: 1 block_len: 16384

# at 180597

#130718 3:17:14 server id 1 end_log_pos 197004

#Append_block: file_id: 1 block_len: 16384

# at 197004

#130718 3:17:14 server id 1 end_log_pos 213411

#Append_block: file_id: 1 block_len: 16384

# at 213411

#130718 3:17:14 server id 1 end_log_pos 229818

#Append_block: file_id: 1 block_len: 16384

# at 229818

#130718 3:17:14 server id 1 end_log_pos 246225

#Append_block: file_id: 1 block_len: 16384

# at 246225

#130718 3:17:14 server id 1 end_log_pos 262632

#Append_block: file_id: 1 block_len: 16384

# at 262632

#130718 3:17:14 server id 1 end_log_pos 279039

#Append_block: file_id: 1 block_len: 16384

# at 279039

#130718 3:17:14 server id 1 end_log_pos 295446

#Append_block: file_id: 1 block_len: 16384

# at 295446

#130718 3:17:14 server id 1 end_log_pos 311853

#Append_block: file_id: 1 block_len: 16384

# at 311853

#130718 3:17:14 server id 1 end_log_pos 328260

#Append_block: file_id: 1 block_len: 16384

# at 328260

#130718 3:17:14 server id 1 end_log_pos 344667

#Append_block: file_id: 1 block_len: 16384

# at 344667

#130718 3:17:14 server id 1 end_log_pos 361074

#Append_block: file_id: 1 block_len: 16384

# at 361074

#130718 3:17:14 server id 1 end_log_pos 377481

#Append_block: file_id: 1 block_len: 16384

# at 377481

#130718 3:17:14 server id 1 end_log_pos 393888

#Append_block: file_id: 1 block_len: 16384

# at 393888

#130718 3:17:14 server id 1 end_log_pos 410295

#Append_block: file_id: 1 block_len: 16384

# at 410295

#130718 3:17:14 server id 1 end_log_pos 426702

#Append_block: file_id: 1 block_len: 16384

# at 426702

#130718 3:17:14 server id 1 end_log_pos 443109

#Append_block: file_id: 1 block_len: 16384

# at 443109

#130718 3:17:14 server id 1 end_log_pos 459516

#Append_block: file_id: 1 block_len: 16384

# at 459516

#130718 3:17:14 server id 1 end_log_pos 475923

#Append_block: file_id: 1 block_len: 16384

# at 475923

#130718 3:17:14 server id 1 end_log_pos 492330

#Append_block: file_id: 1 block_len: 16384

# at 492330

#130718 3:17:14 server id 1 end_log_pos 508737

#Append_block: file_id: 1 block_len: 16384

# at 508737

#130718 3:17:14 server id 1 end_log_pos 525144

#Append_block: file_id: 1 block_len: 16384

# at 525144

#130718 3:17:14 server id 1 end_log_pos 541551

#Append_block: file_id: 1 block_len: 16384

# at 541551

#130718 3:17:14 server id 1 end_log_pos 557958

#Append_block: file_id: 1 block_len: 16384

# at 557958

#130718 3:17:14 server id 1 end_log_pos 574365

#Append_block: file_id: 1 block_len: 16384

# at 574365

#130718 3:17:14 server id 1 end_log_pos 590772

#Append_block: file_id: 1 block_len: 16384

# at 590772

#130718 3:17:14 server id 1 end_log_pos 607179

#Append_block: file_id: 1 block_len: 16384

# at 607179

#130718 3:17:14 server id 1 end_log_pos 623586

#Append_block: file_id: 1 block_len: 16384

# at 623586

#130718 3:17:14 server id 1 end_log_pos 639993

#Append_block: file_id: 1 block_len: 16384

# at 639993

#130718 3:17:14 server id 1 end_log_pos 656400

#Append_block: file_id: 1 block_len: 16384

# at 656400

#130718 3:17:14 server id 1 end_log_pos 672807

#Append_block: file_id: 1 block_len: 16384

# at 672807

#130718 3:17:14 server id 1 end_log_pos 689214

#Append_block: file_id: 1 block_len: 16384

# at 689214

#130718 3:17:14 server id 1 end_log_pos 705621

#Append_block: file_id: 1 block_len: 16384

# at 705621

#130718 3:17:14 server id 1 end_log_pos 722028

#Append_block: file_id: 1 block_len: 16384

# at 722028

#130718 3:17:14 server id 1 end_log_pos 738435

#Append_block: file_id: 1 block_len: 16384

# at 738435

#130718 3:17:14 server id 1 end_log_pos 754842

#Append_block: file_id: 1 block_len: 16384

# at 754842

#130718 3:17:14 server id 1 end_log_pos 771249

#Append_block: file_id: 1 block_len: 16384

# at 771249

#130718 3:17:14 server id 1 end_log_pos 787656

#Append_block: file_id: 1 block_len: 16384

# at 787656

#130718 3:17:14 server id 1 end_log_pos 804063

#Append_block: file_id: 1 block_len: 16384

# at 804063

#130718 3:17:14 server id 1 end_log_pos 820470

#Append_block: file_id: 1 block_len: 16384

# at 820470

#130718 3:17:14 server id 1 end_log_pos 836877

#Append_block: file_id: 1 block_len: 16384

# at 836877

#130718 3:17:14 server id 1 end_log_pos 853284

#Append_block: file_id: 1 block_len: 16384

# at 853284

#130718 3:17:14 server id 1 end_log_pos 869691

#Append_block: file_id: 1 block_len: 16384

# at 869691

#130718 3:17:14 server id 1 end_log_pos 886098

#Append_block: file_id: 1 block_len: 16384

# at 886098

#130718 3:17:14 server id 1 end_log_pos 902505

#Append_block: file_id: 1 block_len: 16384

# at 902505

#130718 3:17:14 server id 1 end_log_pos 918912

#Append_block: file_id: 1 block_len: 16384

# at 918912

#130718 3:17:14 server id 1 end_log_pos 935319

#Append_block: file_id: 1 block_len: 16384

# at 935319

#130718 3:17:14 server id 1 end_log_pos 951726

#Append_block: file_id: 1 block_len: 16384

# at 951726

#130718 3:17:14 server id 1 end_log_pos 968133

#Append_block: file_id: 1 block_len: 16384

# at 968133

#130718 3:17:14 server id 1 end_log_pos 984540

#Append_block: file_id: 1 block_len: 16384

# at 984540

#130718 3:17:14 server id 1 end_log_pos 1000947

#Append_block: file_id: 1 block_len: 16384

# at 1000947

#130718 3:17:14 server id 1 end_log_pos 1017354

#Append_block: file_id: 1 block_len: 16384

# at 1017354

#130718 3:17:14 server id 1 end_log_pos 1033761

#Append_block: file_id: 1 block_len: 16384

# at 1033761

#130718 3:17:14 server id 1 end_log_pos 1050168

#Append_block: file_id: 1 block_len: 16384

# at 1050168

#130718 3:17:14 server id 1 end_log_pos 1066575

#Append_block: file_id: 1 block_len: 16384

# at 1066575

#130718 3:17:14 server id 1 end_log_pos 1082982

#Append_block: file_id: 1 block_len: 16384

# at 1082982

#130718 3:17:14 server id 1 end_log_pos 1099389

#Append_block: file_id: 1 block_len: 16384

# at 1099389

#130718 3:17:14 server id 1 end_log_pos 1115796

#Append_block: file_id: 1 block_len: 16384

# at 1115796

#130718 3:17:14 server id 1 end_log_pos 1132203

#Append_block: file_id: 1 block_len: 16384

# at 1132203

#130718 3:17:14 server id 1 end_log_pos 1148610

#Append_block: file_id: 1 block_len: 16384

# at 1148610

#130718 3:17:14 server id 1 end_log_pos 1165017

#Append_block: file_id: 1 block_len: 16384

# at 1165017

#130718 3:17:14 server id 1 end_log_pos 1181424

#Append_block: file_id: 1 block_len: 16384

# at 1181424

#130718 3:17:14 server id 1 end_log_pos 1197831

#Append_block: file_id: 1 block_len: 16384

# at 1197831

#130718 3:17:14 server id 1 end_log_pos 1214238

#Append_block: file_id: 1 block_len: 16384

# at 1214238

#130718 3:17:14 server id 1 end_log_pos 1230645

#Append_block: file_id: 1 block_len: 16384

# at 1230645

#130718 3:17:14 server id 1 end_log_pos 1247052

#Append_block: file_id: 1 block_len: 16384

# at 1247052

#130718 3:17:14 server id 1 end_log_pos 1263459

#Append_block: file_id: 1 block_len: 16384

# at 1263459

#130718 3:17:14 server id 1 end_log_pos 1279866

#Append_block: file_id: 1 block_len: 16384

# at 1279866

#130718 3:17:14 server id 1 end_log_pos 1296273

#Append_block: file_id: 1 block_len: 16384

# at 1296273

#130718 3:17:14 server id 1 end_log_pos 1312680

#Append_block: file_id: 1 block_len: 16384

# at 1312680

#130718 3:17:14 server id 1 end_log_pos 1329087

#Append_block: file_id: 1 block_len: 16384

# at 1329087

#130718 3:17:14 server id 1 end_log_pos 1345494

.........

#Append_block: file_id: 1 block_len: 16384

# at 4298754

#130718 3:17:14 server id 1 end_log_pos 4315161

#Append_block: file_id: 1 block_len: 16384

# at 4315161

#130718 3:17:14 server id 1 end_log_pos 4331568

#Append_block: file_id: 1 block_len: 16384

# at 4331568

#130718 3:17:14 server id 1 end_log_pos 4347975

#Append_block: file_id: 1 block_len: 16384

# at 4347975

#130718 3:17:14 server id 1 end_log_pos 4364382

#Append_block: file_id: 1 block_len: 16384

# at 4364382

#130718 3:17:14 server id 1 end_log_pos 4380789

#Append_block: file_id: 1 block_len: 16384

# at 4380789

#130718 3:17:14 server id 1 end_log_pos 4397196

#Append_block: file_id: 1 block_len: 16384

# at 4397196

#130718 3:17:14 server id 1 end_log_pos 4413603

#Append_block: file_id: 1 block_len: 16384

# at 4413603

#130718 3:17:14 server id 1 end_log_pos 4430010

#Append_block: file_id: 1 block_len: 16384

# at 4430010

#130718 3:17:14 server id 1 end_log_pos 4446417

#Append_block: file_id: 1 block_len: 16384

# at 4446417

#130718 3:17:14 server id 1 end_log_pos 4462824

#Append_block: file_id: 1 block_len: 16384

# at 4462824

#130718 3:17:14 server id 1 end_log_pos 4479231

#Append_block: file_id: 1 block_len: 16384

# at 4479231

#130718 3:17:14 server id 1 end_log_pos 4495638

#Append_block: file_id: 1 block_len: 16384

# at 4495638

#130718 3:17:14 server id 1 end_log_pos 4512045

#Append_block: file_id: 1 block_len: 16384

# at 4512045

#130718 3:17:14 server id 1 end_log_pos 4528452

#Append_block: file_id: 1 block_len: 16384

# at 4528452

#130718 3:17:14 server id 1 end_log_pos 4544859

#Append_block: file_id: 1 block_len: 16384

# at 4544859

#130718 3:17:14 server id 1 end_log_pos 4561266

#Append_block: file_id: 1 block_len: 16384

# at 4561266

#130718 3:17:14 server id 1 end_log_pos 4577673

#Append_block: file_id: 1 block_len: 16384

# at 4577673

#130718 3:17:14 server id 1 end_log_pos 4594080

#Append_block: file_id: 1 block_len: 16384

# at 4594080

#130718 3:17:14 server id 1 end_log_pos 4610487

#Append_block: file_id: 1 block_len: 16384

# at 4610487

#130718 3:17:14 server id 1 end_log_pos 4626894

#Append_block: file_id: 1 block_len: 16384

# at 4626894

#130718 3:17:14 server id 1 end_log_pos 4643301

#Append_block: file_id: 1 block_len: 16384

# at 4643301

#130718 3:17:14 server id 1 end_log_pos 4659708

#Append_block: file_id: 1 block_len: 16384

# at 4659708

#130718 3:17:14 server id 1 end_log_pos 4676115

#Append_block: file_id: 1 block_len: 16384

# at 4676115

#130718 3:17:14 server id 1 end_log_pos 4692522

#Append_block: file_id: 1 block_len: 16384

# at 4692522

#130718 3:17:14 server id 1 end_log_pos 4708929

#Append_block: file_id: 1 block_len: 16384

# at 4708929

#130718 3:17:14 server id 1 end_log_pos 4725336

#Append_block: file_id: 1 block_len: 16384

# at 4725336

#130718 3:17:14 server id 1 end_log_pos 4735417

#Append_block: file_id: 1 block_len: 10058

# at 4735417

#130718 3:17:14 server id 1 end_log_pos 4735701 Execute_load_query thread_id=98119 exec_time=2 error_code=0

SET TIMESTAMP=1374117434/*!*/;

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

#130718 3:17:14 server id 1 end_log_pos 4735728 Xid = 297745

COMMIT/*!*/;

DELIMITER ;

# End of log file

ROLLBACK /* added by mysqlbinlog */;

/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

确实没有insert之类的sql语句，当用binlog日志进行恢复的时候，会报错的，所以在生产环境上面，最好不要使用load data的方式进行数据导入。以免需要及时恢复数据的时候发生异常。

-- 察看binlog事件,会看到最后的load data local infile纪录.

[sql] view plaincopyprint?

mysql> show binlog events in "mysql-bin.000001";

......

| mysql-bin.000001 | 4708929 | Append_block | 1 | 4725336 | ;file_id=1;block_len=16384 |

| mysql-bin.000001 | 4725336 | Append_block | 1 | 4735417 | ;file_id=1;block_len=10058 |

| mysql-bin.000001 | 4735417 | Execute_load_query | 1 | 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 | 1 | 4735728 | COMMIT /* xid=297745 */

-- 再察看从库数据也都同步复制过去了,再看从库的binlog日志

# at 31990800

#130718 11:15:02 server id 1 end_log_pos 31991105 Query thread_id=97960 exec_time=4294967292 error_code=0

use test/*!*/;

SET TIMESTAMP=1374117302/*!*/;

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 31991105

#130718 11:17:14 server id 1 end_log_pos 31991169 Query thread_id=98119 exec_time=4 error_code=0

SET TIMESTAMP=1374117434/*!*/;

SET @@session.sql_mode=4194304/*!*/;

BEGIN

/*!*/;

# at 31991169

#130718 11:17:14 server id 1 end_log_pos 34088344

#Begin_load_query: file_id: 1 block_len: 2097152

# at 34088344

#130718 11:17:14 server id 1 end_log_pos 36185519

#Append_block: file_id: 1 block_len: 2097152

# at 36185519

#130718 11:17:14 server id 1 end_log_pos 36572432

#Append_block: file_id: 1 block_len: 386890

# at 36572432

#130718 11:17:14 server id 1 end_log_pos 36572723 Execute_load_query thread_id=98119 exec_time=4 error_code=0

SET TIMESTAMP=1374117434/*!*/;

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 36572723

#130718 11:17:14 server id 1 end_log_pos 36572750 Xid = 839475877

COMMIT/*!*/;

-- 再去主库从库上面的tmp目录察看临时文件存在情况,果然看到SQL_LOAD_MB-1-0文件存在.

[root@eanshlt2mydbc001db002 tmp]# ll -t /tmp/ |more

total 2212772

-rw-r----- 1 root root 4581194 Jul 18 11:46 SQL_LOAD_MB-1-0bitsCN.com

f68f2add0b68e4f9810432fce46917b7.png

本文原创发布php中文网，转载请注明出处，感谢您的尊重！

Starting MySQL... ERROR! The server quit without updating PID file (/usr/local/mysql/mysql-bin/data/
知识改变命运，ヾ(◍°∇°◍)ﾉﾞ【求关注】
02-07 4386
最近在服务器上面搭建了宿主机–版本的mysql：5.7报错如下：Starting MySQL… ERROR!
MySQL里load data遇到的问题及解决方法
03-29
此方法并不适应全部的情况，仅供借鉴、参考
Mysql 日志
草原孤狼的专栏
10-20 334
日志是mysql数据库的重要组成部分，记录着数据库运行期间各种状态信息。mysql日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。 作为开发，我们重点需要关注的是二进制日志(binlog)和事务日志(包括redo log和undo log)，本文接下来会详细介绍这三种日志。 binlog binlog用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。binlog是mysql的逻辑日志，并且由Server层进行记录，使用任...
mysql load 记录日志_mysql日志
weixin_28752627的博客
01-27 846
目录错误日志错误日志相关参数查询日志查询日志相关参数慢查询日志慢查询日志相关参数二进制日志二进制日志相关参数二进制日志的三种记录方式二进制日志进行数据库恢复错误日志错误日志会记录如下信息mysql执行过程中的错误信息mysql执行过程中的告警信息event scheduler运行时所产生信息mysq启动和停止过程中产生的信息主从复制结构中，重从服务器IO复杂线程的启动信息错误日志相关参数Maria...
mysql 日志实现_将日志记录在是mysql中，实现loganalyzer
weixin_36440941的博客
01-19 213
三台主机192.168.191.106(代号106) 产生日志192.168.191.107(代号107) 实现存放日志的数据库192.168.191.173(代号173) 实现日志报表1、实现rsyslog将日志记录于MySQL中(1)在107上：yum install mariadb-serversystemctl start mariadbmysql_secure_install...
使用Python解析并“篡改”MySQL的Binlog---发表到爱可生开源社区
姚远OracleACE的博客
09-28 2174
文章目录前言Binlog的结构恢复误删除的记录找出 Binlog 中的大事务切割 Binlog 中的大事务后记 前言 MySQL 的 Binlog 记录着 MySQL 数据库的所有变更信息，了解 Binlog 的结构可以帮助我们解析Binlog，甚至对 Binlog 进行一些修改，或者说是“篡改”，例如实现类似于 Oracle 的 flashback 的功能，恢复误删除的记录，把 update 的记录再还原回去等。本文将带您探讨一下这些神奇功能的实现，您会发现比您想象地要简单得多。本文指的 Binlog 是
mysql 远程load data_mysql导入数据load data infile用法整理
weixin_32183107的博客
01-18 1954
有时候我们需要将大量数据批量写入数据库，直接使用程序语言和Sql写入往往很耗时间，其中有一种方案就是使用MySql Load data infile导入文件的形式导入数据，这样可大大缩短数据导入时间。假如是从MySql客户端调用，将客户端的文件导入，则需要使用 load local data infile.LOAD DATA INFILE 语句以很高的速度从一个文本文件中读取行到一个表中。文件名必...
mysql-binlog二进制日志恢复
04-18
MySQL 二进制日志恢复 MySQL 的二进制日志（binlog）是 MySQL server 的一个重要组件，记录了 MySQL 服务器的所有操作，包括 DML、DDL 等。...使用 mysqlbinlog 工具可以轻松地从二进制日志文件中恢复数据。
MySQL 日志之 binlog 格式 → 关于 MySQL 默认隔离级别的探讨
2401_88972404的博客
01-13 714
我们来看看 MySQL Bug23051，里面有说到，MySQL 5.1 的早期版本，隔离级别是 RC、binlog 格式是STATEMENT时，InnoDB 的主从复制是有 bug 的（5.1.21 中修复），而 5.0.x 是没问题的，我们在 5.0.96 上跑下 Bug23051 中的例子。UPDATE 就有需要注意的了，虽然我们修改列只有一列，条件列也只有一列，但是日志中记录的却是：修改列是全部列，条件列也是全部列，并且列值是具体的值，而没有 NOW()、UUID() 这样的函数。
mysql 大事务 binlog_如何快速找到MYSQL binlog中的大事物以及生成量分布(infobin工具)...
weixin_29023079的博客
01-18 1107
原创注明出处：1、问题引出：某些时候需要判断binlog中是否有大事物的存在，比如在解决master-slave延迟高的情况下。一般我们使用mysqlbinlog来找，但是遇到一个问题，使用mysqbinlog来找比较麻烦，有没有一个快速的方法呢？当然使用shell脚本来做一些格式化，也可以找到，这里介绍一个工具叫做infobin 来做，是我自己编写的用C语言完成2、infobin能做什么？--找...
mysql中的load命令使用方法
12-15
使用mysql 中的load 命令，讲txt 文件中的内容加载到数据库表中，例如,创建table，名称是user，一个字段username；当前有db.txt文件,内容是以空格分开的用户名，例如：xiaowang xiaoliu zhangsan 将该文件加载到数据表user中，使用命令即可： 代码如下: load data local infile “/home/beaver/db” into table user lines terminated by ‘ ‘;  作者 Beaver’s LOAD DATA INFILE 这是我们要介绍的最后一个导入数据到MySQL数据库中的方法。这个命
mysql load 记录日志_MySql--redo日志（上）---WAL
weixin_39584571的博客
01-27 182
具体细节 请去掘金购买《MySQL 是怎样运行的：从根儿上理解 MySQL》redo日志row_id隐藏列赋值的方式1.服务器会在内存中维护一个全局变量，每当向某个包含隐藏的row_id列的表中插入一条记录时，就会把该变量的值当作新记录的row_id列的值，并且把该变量自增1。2.每当这个变量的值为256的倍数时，就会将该变量的值刷新到系统表空间的页号为7的页面中一个称之为Max Row ID的属...
load data 方式导入的数据不可以用binlog日志进行恢复
12-06 239
QQ群里面有人问起这个问题: 用loaddata导入数据的时候，在binlog文件中记录的不是insert语句,这样的话，如果用loaddata导入数据，当需要恢复数据库的时候binlog恢复就不行了 ...
mysql批量导入日志的方法：load data命令
Jepson的博客
06-27 2637
load命令 load data infile 语句从一个文本文件中以很高的速度读入一个表中。使用这个命令之前，mysqld进程（服务）必须已经在运行。由于安全原因，当读取位于服务器上的文件时，文件必须处于数据库目录或可被所有人读取。另外，为了对服务器上文件使用load data infile，在服务器主机上必须有file的权限。 基本语法： load data [low_priority] [local] infile 'file_name.csv' [replace | ignore] 　　into
MYSQL数据库日志
mocas_wang的博客
08-29 3961
目录 1.日志介绍 2. 日志作用 3. 日志分类 Mysql数据库日志 4 .日志讲解 一、innodb引擎中的redo/undo log是什么 二、什么是binlog 三、binlog的三种模式 5. 日志原理 事务的原语操作 延迟的数据库修改redo 立即的数据库修改undo + redo 缓冲区管理 日志缓冲 数据库缓冲 操作系统在缓冲区管理的作用 检查点 静态检查点 动态检查点 对比 1.日志介绍 数据库都具有事务日志，用于记录所有事务以及每个事务对数据
mysql查看执行日志
qq_39459099的博客
08-29 1226
1.show variables like 'log_bin' 查看是否开启日志 ON表示已开启 2.开启日志show variableslike'%general%'; 开启查询日志SETGLOBALgeneral_log ='On'; 指定查询日志文件 SETGLOBALgeneral_log_file ='/var/lib/mysql/mysql.log';...
mysql 的执行记录日志文件_mysql 重要日志文件汇总
weixin_28979339的博客
01-19 390
日志是所有应用的重要数据，MySQL 也有错误日志、查询日志、慢查询日志、事务日志等。本文简单总结下各种日志，以备查阅。二进制日志 binlog二进制日志 binlog 用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。使用任何存储引擎的 mysql 数据库都会记录 binlog 日志。在 binlog 中记录的是逻辑日志，也就是 SQL 语句。SQL 语句执行后，bi...
mysql语句之load data
weixin_40927846的博客
01-18 735
语法： load data [low_priority] [local] infile 'file_name' [replace | ignore] into table 'table_name' [fields [terminated by 'char'] [OPTIONALLY] enclosed by 'char'] [escaped by 'char'] ] [lines...
深入浅出MySQL(十一)关于mysql里面的bin-log日志
Danny_idea的博客
01-22 233
mysql里面的bin-log日志，相信大家都有过相应的了解，但是对于bin-log日志而言，具体的内容是做什么的，今天小编特意抽空学习了一下，下边是我的笔记心得。 主从同步的一个基本原理 MySQL的二进制日志可以说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。 由于在主从架构...
1，一直有MySQL日志文件stu335d05-bin.000072，其事件如下图，请将其中写入又删除的记录进行恢复，写出操作步骤 2，有如下图所示的fc.png图片，如何操作可以实现将密码隐藏在图片底端？
最新发布
07-03
<think>我们首先分析用户的问题。用户有两个需求：1.从MySQL日志文件（stu335d05-bin.000072）中恢复被写入后又删除的数据。2.将密码隐藏在fc.png图片的底部。关于第一个需求：MySQL的日志文件通常是二进制日志（binlog），记录了所有对数据库的修改操作，包括写入和删除。要恢复被删除的数据，我们需要解析binlog文件，找到对应的删除操作，并获取删除前的数据。操作步骤：步骤1：确保有MySQL的binlog解析工具。常用的工具是`mysqlbinlog`，它是MySQL自带的。步骤2：使用`mysqlbinlog`解析指定的binlog文件，并输出为可读的文本文件或SQL文件。步骤3：在解析出的内容中查找删除操作（DELETE语句），并记录下删除前的数据。注意，binlog中可能包含多个事务，需要仔细筛选。但是，需要注意的是，binlog默认是ROW格式，它会记录每一行被删除的数据（如果是行级复制）。因此，我们可以通过解析binlog来获取被删除的每一行的完整数据。具体命令：1.将binlog文件转换为文本文件：```bashmysqlbinlog --base64-output=decode-rows -v -v stu335d05-bin.000072 >binlog.txt```这里使用`-v -v`（两个verbose）是为了在ROW格式下显示详细的SQL语句（包括注释形式的行数据）。2.打开binlog.txt文件，搜索删除操作。通常，删除操作会以如下形式出现：```###DELETE FROM`database`.`table`### WHERE###@1=...#对应第一列的值###@2=...#对应第二列的值...```在ROW格式下，`DELETE`语句会记录删除前每一列的值，这些值就是我们需要恢复的数据。3.将找到的数据重新整理成INSERT语句，插入回数据库（如果需要）或者直接保存。注意：如果binlog文件较大，可以使用时间范围或位置范围来缩小解析范围。关于第二个需求：将密码隐藏在fc.png图片的底部。我们可以使用图片隐写术（steganography）来实现。其中一种简单的方法是将密码以文本形式追加到图片文件的末尾。这样图片仍然可以正常显示，但通过文本编辑器打开图片文件，在文件末尾可以看到追加的密码。操作步骤：方法1：使用命令行（例如Linux的cat命令）```bashcatfc.png >new_image.pngecho "your_password" >>new_image.png```这样，密码就被追加到了图片的末尾。但是，这种方法在图片被打开时不会影响显示，因为图片格式解析时会忽略文件末尾的额外数据。但是，这种方法很容易被发现。方法2：使用专门的隐写工具，如steghide、outguess等，但需要密码才能提取。这里用户要求将密码隐藏在图片底部，可能是指视觉上的底部，即图片内容底部。但这样需要修改图片内容，而不是文件末尾。所以我们需要澄清：-如果用户希望视觉上在图片底部显示密码（即明文显示），则可以使用图像编辑软件（如Photoshop）在图片底部添加文字。-如果用户希望以不可见的方式隐藏，但可以在文件末尾追加，则使用方法1。但是，根据问题描述，用户要求将密码隐藏在图片底部，可能是指文件末尾。因此我们采用方法1。然而，为了确保图片的完整性，我们也可以考虑将密码写入图片的元数据（如EXIF信息）中，但这样需要专门的工具。考虑到简单性，我们采用方法1。总结操作步骤：1.将原始图片（fc.png）复制一份，例如命名为fc_with_password.png。2.在fc_with_password.png文件末尾追加密码字符串。注意：这种方法在Windows下也可以使用记事本打开图片并追加，但可能会破坏图片？实际上，图片格式在文件末尾追加数据通常不会影响图片的显示，因为图片查看器会忽略末尾多余的数据。但是，为了确保安全，最好使用二进制编辑器追加。在Windows下，可以使用命令行（cmd）：```copy/b fc.png +password.txt fc_with_password.png```其中，password.txt是一个文本文件，里面只有一行密码。或者使用echo追加：```copy /b fc.png +confc_with_password.png```然后输入密码并按Ctrl+Z结束。但这比较复杂，建议使用第一种方法。或者使用PowerShell：```powershellGet-Content fc.png -Encoding Byte-Raw| Set-Contentfc_with_password.png -Encoding Byte-NoNewlineAdd-Content fc_with_password.png -Value"your_password"-EncodingUTF8 -NoNewline```但是注意，Add-Content默认会添加换行，所以使用-NoNewline。但是，这样可能会将密码作为二进制数据的一部分，而不是文本。实际上，我们追加的是文本，所以图片查看器可能无法显示（但不会影响原图数据）。因此，使用简单的追加文本是可行的。考虑到跨平台，我们推荐使用Linux命令，或者使用Python脚本：使用Python脚本：```pythonwith open('fc.png','rb') asf:data= f.read()password= "your_password"withopen('fc_with_password.png', 'wb')as f:f.write(data)f.write(password.encode('utf-8'))```这样，密码就被追加到了图片的末尾。现在，我们来回答用户的问题，并提供操作步骤。</think>### 从MySQL日志恢复被删除数据的操作步骤 #### 1. **定位目标binlog文件** 确认MySQL日志路径（通常为`/var/lib/mysql/`），找到指定文件`stu335d05-bin.000072`。 #### 2. **解析binlog内容** 使用MySQL官方工具`mysqlbinlog`解析日志： ```bash mysqlbinlog --base64-output=decode-rows -vv \ --start-datetime="2023-01-01 00:00:00" \ # 指定操作时间范围 stu335d05-bin.000072 > binlog_analysis.sql ``` - `--base64-output=decode-rows`：解码行级操作 - `-vv`：显示详细数据变化 - 时间范围根据实际删除操作发生时间调整 #### 3. **识别删除操作** 在生成的`binlog_analysis.sql`中搜索： ```sql ### DELETE FROM `目标表` ### WHERE ### @1=... # 列1的值 ### @2=... # 列2的值 ``` 每个`@n`对应表字段，记录被删除行的完整数据[^1]。 #### 4. **数据恢复** 将识别出的数据转换为INSERT语句： ```sql INSERT INTO `目标表` VALUES (@1, @2, ...); ``` 在MySQL中执行恢复数据。 #### 5. **验证恢复** 查询目标表确认数据是否存在： ```sql SELECT * FROM `目标表` WHERE 主键字段 = '被删除记录ID'; ``` > **注意**：需开启binlog的`ROW`格式才能记录完整行数据。检查配置： > ```sql > SHOW VARIABLES LIKE 'binlog_format'; > ``` --- ### 将密码隐藏到图片底部的操作步骤 #### 方法1：文件末尾追加（隐写术） ```bash # 将密码追加到图片二进制末尾 echo "YourPassword" >> fc.png # 验证隐藏内容 tail -c 50 fc.png # 显示文件末尾50字节 ``` #### 方法2：EXIF元数据写入 使用`exiftool`写入注释字段： ```bash exiftool -Comment="YourPassword" fc.png # 读取验证 exiftool fc.png | grep Comment ``` #### 方法3：像素隐写（Python实现） ```python from PIL import Image def hide_text_in_image(image_path, text): img = Image.open(image_path) pixels = img.load() width, height = img.size # 将文本编码为二进制 binary_text = ''.join(format(ord(c), '08b') for c in text) binary_text += '00000000' # 结束标记 # 修改底部像素LSB index = 0 for y in range(height-10, height): # 底部10行像素 for x in range(width): if index >= len(binary_text): break r, g, b = pixels[x, y] # 修改蓝色通道最低位 b = (b & 0xFE) | int(binary_text[index]) pixels[x, y] = (r, g, b) index += 1 img.save("hidden_fc.png") hide_text_in_image("fc.png", "YourPassword") ``` > **验证隐藏效果**： > - 文件末尾追加：用文本编辑器打开图片滚动到底部 > - EXIF方式：右键查看图片属性 > - 像素隐写：需专用工具提取（如StegSolve） --- ### 相关问题 1. MySQL的`ROW`格式binlog和`STATEMENT`格式在数据恢复中有何区别？ 2. 如何防止追加隐写后的图片被社交平台二次压缩破坏隐藏信息？ 3. 除了binlog，还有哪些MySQL日志可用于数据恢复（如undo log/redo log）？ 4. 在像素隐写术中，如何平衡隐藏容量与图片视觉质量？ [^1]: MySQL binlog解析原理，[官方文档](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html) [^2]: 图片隐写技术实现，[Steganography研究综述](https://doi.org/10.1109/ACCESS.2020.3041079)
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值