首页 / 日志 / MySQLbinlog日志02binlog日志用于数据恢复

MySQLbinlog日志02binlog日志用于数据恢复

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了MySQLbinlog日志02binlog日志用于数据恢复，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含19044字，纯文字阅读大概需要28分钟。

内容图文

binlog日志恢复数据

binlog数据库闪回工具myfash

1. binlog日志的记录次序

binlog日志是在事务提交时才写入到binlog日志文件中的，这就决定了binlog日志文件中的事件记录的次序由所在的事务提交的时间点的次序决定，而不是由SQL语句执行时的次序决定。因此binlog日志文件中，每个事务作为整体依据事务提交的次序排列，每个事件内部的各个事件按照时间次序先后排列。

按照以下操作可以验证上述结论。

先建立一个表：

mysql> create table t5 (id int auto_increment primary key, who varchar (10) , time timestamp default current_timestamp on update current_timestamp );

Query OK, 0 rows affected (0.01 sec)

其中id字段表示记录被添加的次序， who字段表示那个事务添加的， time字段表示添加时的时间戳。

时间次序	事务A	事务B
1	begin;
2	insert into t5 (who) values (‘A‘);
3		begin;
4		insert into t5 (who) values (‘B‘);
5	insert into t5 (who) values (‘A‘);
6		insert into t5 (who) values (‘B‘);
7		commit;
8	insert into t5 (who) values (‘A‘);
9	commit;

执行结果如下：

mysql> select * from t5;

+----+------+---------------------+

| id | who | time |

+----+------+---------------------+

| 1 | A | 2018-09-20 22:05:25 |

| 2 | B | 2018-09-20 22:06:11 |

| 3 | A | 2018-09-20 22:06:51 |

| 4 | B | 2018-09-20 22:07:00 |

| 5 | A | 2018-09-20 22:07:21 |

+----+------+---------------------+

5 rows in set (0.00 sec)

查看binlog事件信息：

使用以下命令也可以查看到这两个事务的全部binlog事件信息，同样可以观察到这个现象。

mysqlbinlog --base64-output=DECODE-ROWS mysql_binlog.000003 -vv

也可以使用以下的命令仅仅查看binlog文件中的SQL语句信息(这些SQL语句不是通常的SQL语句，有比较独特的语法，不能独立执行)：

[root@101 binlog]# mysqlbinlog -v --base64-output=DECODE-ROWS mysql_binlog.000003 |grep -E -v "^\/\*" |grep -E "^(###)|(COMMIT)"|sed ‘s/^### //g‘

INSERT INTO `binlog`.`t5`

SET

@1=2

@2=‘B‘

@3=1537452371

INSERT INTO `binlog`.`t5`

SET

@1=4

@2=‘B‘

@3=1537452420

COMMIT/*!*/;

INSERT INTO `binlog`.`t5`

SET

@1=1

@2=‘A‘

@3=1537452325

INSERT INTO `binlog`.`t5`

SET

@1=3

@2=‘A‘

@3=1537452411

INSERT INTO `binlog`.`t5`

SET

@1=5

@2=‘A‘

@3=1537452441

COMMIT/*!*/;

可以看到事务B的全部事件排列在前面，然后才是事务A的全部事件。事务A内部的各个事件按照执行的时间次序排列，事务B也是。

经过实际验证，这个次序跟事务隔离级别没有关系，在READ COMMITTED和REPEATABLE READ隔离级别下都是相同的结果。

通过这个操作过程，可以得出3个结论：

（1）事务提交的次序决定事务的事件数据在binlog日志文件中的先后次序，

（2）事务内部的所有事件集中在一起，不同事务的事件不会交叉出现在binlog日志文件中。

（3）事务内部的所有事件按照时间次序排列。

2. binlog日志恢复数据

假设先执行了以下的操作：

mysql> desc t7;

+-------+-------------+------+-----+-------------------+-----------------------------+

+-------+-------------+------+-----+-------------------+-----------------------------+

| id | int(11) | NO | PRI | NULL | auto_increment |

| who | varchar(10) | YES | | NULL | |

+-------+-------------+------+-----+-------------------+-----------------------------+

3 rows in set (0.01 sec)

mysql> insert into t7 (who) values (‘A1‘);

Query OK, 1 row affected (0.01 sec)

mysql> insert into t7 (who) values (‘A2‘);

Query OK, 1 row affected (0.00 sec)

mysql> insert into t7 (who) values (‘A3‘);

Query OK, 1 row affected (0.01 sec)

mysql> insert into t7 (who) values (‘A4‘);

Query OK, 1 row affected (0.00 sec)

mysql> insert into t7 (who) values (‘A5‘);

Query OK, 1 row affected (0.00 sec)

mysql> insert into t7 (who) values (‘A6‘);

Query OK, 1 row affected (0.00 sec)

mysql> insert into t7 (who) values (‘A7‘);

Query OK, 1 row affected (0.01 sec)

mysql> insert into t7 (who) values (‘A8‘);

Query OK, 1 row affected (0.00 sec)

mysql> insert into t7 (who) values (‘A9‘);

Query OK, 1 row affected (0.00 sec)

mysql> insert into t7 (who) values (‘A10‘);

Query OK, 1 row affected (0.00 sec)

mysql> select * from t7;

+----+------+---------------------+

| id | who | time |

+----+------+---------------------+

| 1 | A1 | 2018-09-20 22:55:55 |

| 2 | A2 | 2018-09-20 22:55:57 |

| 3 | A3 | 2018-09-20 22:55:58 |

| 4 | A4 | 2018-09-20 22:56:06 |

| 5 | A5 | 2018-09-20 22:56:08 |

| 6 | A6 | 2018-09-20 22:56:39 |

| 7 | A7 | 2018-09-20 22:56:41 |

| 8 | A8 | 2018-09-20 22:56:43 |

| 9 | A9 | 2018-09-20 22:56:45 |

| 10 | A10 | 2018-09-20 22:56:47 |

+----+------+---------------------+

10 rows in set (0.00 sec)

mysql> create table t8 like t7;

Query OK, 0 rows affected (0.01 sec)

mysql> insert into t8 (who) values (‘B1‘);

Query OK, 1 row affected (0.02 sec)

mysql> insert into t8 (who) values (‘B2‘);

Query OK, 1 row affected (0.00 sec)

mysql> insert into t8 (who) values (‘B3‘);

Query OK, 1 row affected (0.00 sec)

mysql> insert into t8 (who) values (‘B4‘);

Query OK, 1 row affected (0.01 sec)

mysql> insert into t8 (who) values (‘B5‘);

Query OK, 1 row affected (0.00 sec)

mysql> insert into t7 (who) values (‘A100‘);

Query OK, 1 row affected (0.00 sec)

mysql> insert into t7 (who) values (‘A101‘);

Query OK, 1 row affected (0.00 sec)

mysql> select * from t8;

+----+------+---------------------+

| id | who | time |

+----+------+---------------------+

| 1 | B1 | 2018-09-20 22:57:24 |

| 2 | B2 | 2018-09-20 22:57:26 |

| 3 | B3 | 2018-09-20 22:57:28 |

| 4 | B4 | 2018-09-20 22:57:29 |

| 5 | B5 | 2018-09-20 22:57:31 |

+----+------+---------------------+

5 rows in set (0.00 sec)

此时t7和t8表中都有正常数据。

这时由于某种疏忽执行了以下的delete语句。

mysql> delete from t8;

Query OK, 5 rows affected (0.02 sec)

mysql> select * from t8;

Empty set (0.00 sec)

结果是t8表的全部数据都被删除了。

现在的问题是需要恢复这些被删除的数据。

使用binlog可以实现这个目标。

先找到当前使用的binlog文件名称。

mysql> show binary logs;

+---------------------+-----------+

| Log_name | File_size |

+---------------------+-----------+

| mysql_binlog.000001 | 439 |

| mysql_binlog.000002 | 1149 |

| mysql_binlog.000003 | 1319 |

| mysql_binlog.000004 | 361 |

| mysql_binlog.000005 | 1319 |

| mysql_binlog.000006 | 6392 |

+---------------------+-----------+

6 rows in set (0.01 sec)

mysql> flush binary logs;

Query OK, 0 rows affected (0.01 sec)

执行之前那些数据增删操作对应的事件记录在mysql_binlog.000006文件中。

基本的思路是先找到binlog中对t8表的正常操作(insert)的binlog事件，不包括delete语句的事件，然后将这些事件在数据库中重新执行一遍即可。先需要确定这些事件的位置范围的开始位置和结束位置。

在binlog文件还存在的情况下，使用以下SQL语句查询这个binlog文件中的事件。

mysql> show binlog events in ‘mysql_binlog.000006‘;

开始位置：

找到先前执行的t8表的第一个insert事件的开始位置。3805 (BEGIN)

结束位置：

找到先前执行的t8表的最后一个insert事件的结束位置。5375(COMMIT)

在3805到5375范围内的binlog事件全部是t8的insert语句相关的事件。

使用mysqlbinlog提取这些事件产生SQL语句，并通过mysql程序执行提取的SQL语句。

[root@101 binlog]# mysqlbinlog --start-position=3805 --stop-position=5375 mysql_binlog.000006 |mysql -uroot -p123456 -S /tmp/mysql.sock

此时查看t8表的数据：

mysql> select * from t8;

+----+------+---------------------+

| id | who | time |

+----+------+---------------------+

| 1 | B1 | 2018-09-20 22:57:24 |

| 2 | B2 | 2018-09-20 22:57:26 |

| 3 | B3 | 2018-09-20 22:57:28 |

| 4 | B4 | 2018-09-20 22:57:29 |

| 5 | B5 | 2018-09-20 22:57:31 |

+----+------+---------------------+

5 rows in set (0.00 sec)

t8表的数据恢复成功。

在执行这个操作之前，可以先通过以下命令先产生SQL语句，确认无误后再通过mysql程序导入数据。

mysqlbinlog --start-position=3805 --stop-position=5375 mysql_binlog.000006 -vv

可以同时指定位置范围和时间戳范围，这样更准确的过滤数据，可以通过以下命令查看截取的数据。

mysqlbinlog --start-position=3805 --stop-position=5375 --start-datetime=20180920225724 --stop-datetime=20180920225732 -vv mysql_binlog.000006

确认无误后同样根据以下命令导入这部分数据到t8表中。

mysqlbinlog --start-position=3805 --stop-position=5375 --start-datetime=20180920225724 --stop-datetime=20180920225732 -vv mysql_binlog.000006 |mysql -uroot -p123456 -S /tmp/mysql.sock

这个简单的方法的最大缺点是当这个范围内包含有对其它数据表的操作时，这些操作将会影响到其它数据表。

mysqlbinlog还有一些参数：

--disable-log-bin ：作用是本次操作不记录binlog日志。如果不希望本次操作影响到复制中的slave从机，则可以添加这个参数。

--database=XXXX：

在ROW模式下，作用是本次操作仅仅包含对XXXX数据库的操作，跟是否使用use无关。

在SQL模式下，作用比较隐晦，此时最好都通过use语句指定数据库，而不是通过数据库名.表名的方式。

以下文字来自man mysqlbinlog的输出信息：

mysqlbinlog --database=test does not output the first two INSERT statements because there is no default database. It outputs the three INSERT statements following USE test,

but not the three INSERT statements following USE db2.

mysqlbinlog --database=db2 does not output the first two INSERT statements because there is no default database. It does not output the three INSERT statements following USE

test, but does output the three INSERT statements following USE db2.

Row-based logging. mysqlbinlog outputs only entries that change tables belonging to db_name. The default database has no effect on this. Suppose that the binary log just

described was created using row-based logging rather than statement-based logging. mysqlbinlog --database=test outputs only those entries that modify t1 in the test database,

regardless of whether USE was issued or what the default database is. If a server is running with binlog_format set to MIXED and you want it to be possible to use mysqlbinlog

with the --database option, you must ensure that tables that are modified are in the database selected by USE. (In particular, no cross-database updates should be used.)

3. binlog数据库闪回工具myfash

myflash是一款MySQL binlog数据库闪回工具，核心机制是读取binlog文件的INSERT/UPDATE?DELETE事件，并将这些事件的基础上产生相应的逆向（回滚）事件，然后逆序保存到binlog文件中，最后执行这些binlog文件，从而达到数据库快速回滚某一段时间范围或者binlog位置范围内的数据操作的目的。

flashback的参数指定的位置范围和时间范围是“误操作”产生的事件数据的范围，比如前面例子中的误操作就是delete from t8这个SQL语句。因此需要找到这个语句。

通过以下SQL语句来查找，

mysql> show binlog events in ‘mysql_binlog.000006‘;

或者直接通过binlog文件来查找：

# at 6102

#180920 22:58:52 server id 101 end_log_pos 6176 CRC32 0x26716c36 Query thread_id=4 exec_time=0 error_code=0

SET TIMESTAMP=1537455532/*!*/;

BEGIN

/*!*/;

# at 6176

#180920 22:58:52 server id 101 end_log_pos 6214 CRC32 0x763a5d60 Rows_query

# delete from t8

# at 6214

#180920 22:58:52 server id 101 end_log_pos 6266 CRC32 0x33416fc0 Table_map: `binlog`.`t8` mapped to number 145

# at 6266

#180920 22:58:52 server id 101 end_log_pos 6361 CRC32 0xfe4e1cba Delete_rows: table id 145 flags: STMT_END_F

BINLOG ‘

rLWjWx1lAAAAJgAAAEYYAACAAA5kZWxldGUgZnJvbSB0OGBdOnY=

rLWjWxNlAAAANAAAAHoYAAAAAJEAAAAAAAEABmJpbmxvZwACdDgAAwMPEQMKAAAGwG9BMw==

rLWjWyBlAAAAXwAAANkYAAAAAJEAAAAAAAEAAgAD//gBAAAAAkIxW6O1VPgCAAAAAkIyW6O1VvgD

AAAAAkIzW6O1WPgEAAAAAkI0W6O1WfgFAAAAAkI1W6O1W7ocTv4=

‘/*!*/;

### DELETE FROM `binlog`.`t8`

### WHERE

### @1=1 /* INT meta=0 nullable=0 is_null=0 */

### @2=‘B1‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

### @3=1537455444 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

### @1=2 /* INT meta=0 nullable=0 is_null=0 */

### @2=‘B2‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

### @3=1537455446 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

### @1=3 /* INT meta=0 nullable=0 is_null=0 */

### @2=‘B3‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

### @3=1537455448 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

### @1=4 /* INT meta=0 nullable=0 is_null=0 */

### @2=‘B4‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

### @3=1537455449 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

### @1=5 /* INT meta=0 nullable=0 is_null=0 */

### @2=‘B5‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

### @3=1537455451 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

# at 6361

#180920 22:58:52 server id 101 end_log_pos 6392 CRC32 0xeb934c3d Xid = 295

COMMIT/*!*/;

最后找到的位置范围是6102到6392，时间范围180920 22:58:52到180920 22:58:52。

在此基础上，可以执行flashback程序，产生对应的“回滚”binlog日志文件。

root@101 binary]# ./flashback --databaseNames=binlog --tableNames=t8 --start-position=6102 --stop-position=6392 --start-datetime="2018-09-20 22:58:52" --stop-datetime="2018-09-20 22:58:52" --sqlTypes=delete --binlogFileNames=/opt/mysql/binlog/mysql_binlog.000006

产生的binlog日志文件：

binlog_output_base.flashback

使用mysqlbinlog查看这个binlog日志文件的内容：

[root@101 binary]# mysqlbinlog binlog_output_base.flashback -vv

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;

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

DELIMITER /*!*/;

# at 4

#180920 22:45:53 server id 101 end_log_pos 123 CRC32 0x516e9591 Start: binlog v 4, server v 5.7.22-log created 180920 22:45:53

BINLOG ‘

obKjWw9lAAAAdwAAAHsAAAAAAAQANS43LjIyLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA

AZGVblE=

‘/*!*/;

# at 123

#180920 22:58:52 server id 101 end_log_pos 175 CRC32 0x33416fc0 Table_map: `binlog`.`t8` mapped to number 145

# at 175

#180920 22:58:52 server id 101 end_log_pos 270 CRC32 0xfe4e1cba Write_rows: table id 145 flags: STMT_END_F

BINLOG ‘

rLWjWxNlAAAANAAAAK8AAAAAAJEAAAAAAAEABmJpbmxvZwACdDgAAwMPEQMKAAAGwG9BMw==

rLWjWx5lAAAAXwAAAA4BAAAAAJEAAAAAAAEAAgAD//gBAAAAAkIxW6O1VPgCAAAAAkIyW6O1VvgD

AAAAAkIzW6O1WPgEAAAAAkI0W6O1WfgFAAAAAkI1W6O1W7ocTv4=

‘/*!*/;

### INSERT INTO `binlog`.`t8`

### SET

### @1=1 /* INT meta=0 nullable=0 is_null=0 */

### @2=‘B1‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

### @3=1537455444 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

### @1=2 /* INT meta=0 nullable=0 is_null=0 */

### @2=‘B2‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

### @3=1537455446 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

### @1=3 /* INT meta=0 nullable=0 is_null=0 */

### @2=‘B3‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

### @3=1537455448 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

### @1=4 /* INT meta=0 nullable=0 is_null=0 */

### @2=‘B4‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

### @3=1537455449 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

### @1=5 /* INT meta=0 nullable=0 is_null=0 */

### @2=‘B5‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

### @3=1537455451 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

SET @@SESSION.GTID_NEXT= ‘AUTOMATIC‘ /* added by mysqlbinlog */ /*!*/;

DELIMITER ;

# End of log file

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

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

总共包含了5条INSERT语句，正好插入5条数据记录，从而可以借此达到“回滚”的目标。

最后通过mysqlbinlog产生对应的 SQL语句，并通过mysql程序执行，最终恢复了t8表的5条被误操作删除的记录。

[root@101 binary]# mysqlbinlog -vv binlog_output_base.flashback |mysql -uroot -p123456 -S /tmp/mysql.sock

mysql> select * from t8;

+----+------+---------------------+

| id | who | time |

+----+------+---------------------+

| 1 | B1 | 2018-09-20 22:57:24 |

| 2 | B2 | 2018-09-20 22:57:26 |

| 3 | B3 | 2018-09-20 22:57:28 |

| 4 | B4 | 2018-09-20 22:57:29 |

| 5 | B5 | 2018-09-20 22:57:31 |

+----+------+---------------------+

5 rows in set (0.00 sec)

myflash工具的适用条件：

（1）binlog_format=row

如果binlog记录sql语句而不是行记录数据，那么没办法仅仅根据一个sql语句产生反向的“回滚”binlog事件。因此不适用于STATEMENT模式或者MIXED模式。

在STATEMENT模式下，delete from t8对应的binlog数据的内容为：

BEGIN

/*!*/;

# at 302

#180921 0:54:48 server id 101 end_log_pos 394 CRC32 0x3cb196cf Query thread_id=2 exec_time=0 error_code=0

use `binlog`/*!*/;

SET TIMESTAMP=1537462488/*!*/;

delete from t8

/*!*/;

# at 394

#180921 0:54:48 server id 101 end_log_pos 425 CRC32 0xa4634f24 Xid = 21

COMMIT/*!*/;

没有包含任何行记录数据信息，因此myflash工具也没法产生反向操作insert所需要的数据。

（2）binlog_row_image=full

如果binliog中记录的行记录中缺少一部分字段的值，则很可能没办法产生反向的“回滚”binlog事件。

在binlog_row_image=minimal的情况下，delete from t8产生的binlog事件如下：

# delete from t8

# at 331

#180921 0:35:08 server id 101 end_log_pos 383 CRC32 0x571c1559 Table_map: `binlog`.`t8` mapped to number 117

# at 383

#180921 0:35:08 server id 101 end_log_pos 443 CRC32 0xc220f346 Delete_rows: table id 117 flags: STMT_END_F

BINLOG ‘

PMyjWx1lAAAAJgAAAEsBAACAAA5kZWxldGUgZnJvbSB0OO9WEy8=

PMyjWxNlAAAANAAAAH8BAAAAAHUAAAAAAAEABmJpbmxvZwACdDgAAwMPEQMKAAAGWRUcVw==

PMyjWyBlAAAAPAAAALsBAAAAAHUAAAAAAAEAAgADAf4BAAAA/gIAAAD+AwAAAP4EAAAA/gUAAABG

8yDC

‘/*!*/;

### DELETE FROM `binlog`.`t8`

### WHERE

### @1=1 /* INT meta=0 nullable=0 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

### @1=2 /* INT meta=0 nullable=0 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

### @1=3 /* INT meta=0 nullable=0 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

### @1=4 /* INT meta=0 nullable=0 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

### @1=5 /* INT meta=0 nullable=0 is_null=0 */

其中的5条DELETE语句每个仅仅包含了主键字段id的值，而没有包含其它的字段，此时myflash工具无法产生包含完整的原始字段数据的INSERT语句。

此时myflash工具产生的binlog数据如下：

### INSERT INTO `binlog`.`t8`

### SET

### @1=1 /* INT meta=0 nullable=0 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

### @1=2 /* INT meta=0 nullable=0 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

### @1=3 /* INT meta=0 nullable=0 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

### @1=4 /* INT meta=0 nullable=0 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

### @1=5 /* INT meta=0 nullable=0 is_null=0 */

依靠这个数据是没法产生t8表的其它字段的数据的。

（3）只能是INSERT/DELETE/UPDATE这三种语句，而不能是DDL语句，也不能是TRUNCATE TABLE语句。

如果是DDL语句，则可能没法产生反向的“回滚”binlog事件。TRUNCATE TABLE语句产生的binlog事件不包含行数据信息，因此也无法回滚。

MySQLbinlog日志02binlog日志用于数据恢复

标签：条件 datetime his 添加 delete varchar log-bin 独立 mod

本文系统来源：https://www.cnblogs.com/coe2coe/p/9690617.html

内容总结

以上是互联网集市为您收集整理的MySQLbinlog日志02binlog日志用于数据恢复全部内容，希望文章能够帮你解决MySQLbinlog日志02binlog日志用于数据恢复所遇到的程序开发问题。如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/500150.html

来源：【匿名】

首页 / 日志 / MySQLbinlog日志02binlog日志用于数据恢复

MySQLbinlog日志02binlog日志用于数据恢复

内容导读

内容图文

1. binlog日志的记录次序

2. binlog日志恢复数据

3. binlog数据库闪回工具myfash

内容总结

内容备注

内容手机端

【MySQLbinlog日志02binlog日志用于数据恢复】教程文章相关的互联网学习教程文章

mysqlbinlog 查看binlog日志时报错unknown variable 'default-character-set=utf8'【代码】

MySQL的两个日志redo log和 binlog

怎么查看mysql 的binlog日志存放的位置【图】

主从同步工作过程？(binlog日志)

MySQL 5.6 新参数对binlog日志量的优化

无全量备份、未开启binlog日志，利用percona工具恢复delete的数据【图】

MySQL抑制binlog日志中的binlog部分

mysql之binlog日志以及利用binlog日志恢复数据的示例代码分享

详解Mysql数据库之Binlog日志使用代码总结

Mysql中错误日志、binlog日志、查询日志、慢查询日志简介【图】

MySQL自动清理binlog日志的方法

mysql5.6.12切换binlog二进制日志路径_MySQL

mysql正确清理binlog日志的两种方法

解说mysql之binlog日志以及利用binlog日志恢复数据的方法

Mysql数据库之Binlog日志使用总结(必看篇)

MYSQLBINLOG - 相关标签

日志 - 相关标签

日志 - 最新教程

日志 - 最热教程