z0nek

关于我

首先呢。渗透测试过程中发现phpmyadmin二进制日志记录我所有的操作记录。它可以把我所做的操作过程全部恢复。于是百度了一下查看了一些文档。当然不管攻防人员都用得到。

简介:
MySQL的二进制日志可以说或是MySQL最重要的日志了,它记录了所有的DDL和DML(除了数据查询语句)语句,以事件形式记录,还包含语句所执行的消耗的时间,MySQL的二进制日志是失误安全型的.
MySQL的二进制日志的作用是显而易见的,可以方便的备份这些日志以便做数据恢复,也可以作为主从复制的同步文件,然而二进制日志的大小可能会根据不同的需求而存在麻烦,所以让日志回滚是必须的,当然MySQL已经为我们提供了二进制回滚的功能,那就是max_binlog_size参数。

默认MySQL的二进制日志达到1G后就会自动回滚,如果我们想要更小的二进制日志,可以使用max_binlog_size参数来设置。测试使用max_binlog_size=200M,具体应用就是在配置文件里添加这个参数max_binlog_size=200M,官方文档是这样解释的:

mysqld在每个二进制日志名后面添加一个数字扩展名。每次你启动服务器或刷新日志时该数字则增加。如果当前的日志大小达到 max_binlog_size,还会自动创建新的二进制日志。如果你正使用大的事务,二进制日志还会超过 max_binlog_size:事务全写入一个二进制日志中,绝对不要写入不同的二进制日志中。也就是说,在达到max_binlog_size的时候,如果正在处理一个大的事务,那么二进制日志会在处理完这个事务后才会回滚,所以该二进制日志可能会大于所设定的max_binlog_size。
在主从复制的应用中,可能我们不希望二进制日志过大,因为日志过大可能会影响日志的执行效率,适当调整max_binlog_size的值还是非常有意义的,当

mysql开启二进制日志记录文件

# Binary Logging.

log-bin=C:/ProgramData/MySQL/MySQL Server 5.6/log/mybinlog.log

sync_binlog=1

innodb_support_xa=1


1.开启mysql二进制日志:
编辑my.cnf,添加

log-bin=/var/log/mysql/mysql-bin.log

备注:[mysqld] #选项添加

log-bin=mysql-bin #日志文件名称,未指定位置,默认数据文件位置

开启日志后需要myssqladmin flush logs才能生效。
需要注意的是log-bin指定扩展名是无效的,当mysql创建二进制日志文件时。

首先创建一个以“mysql_log_bin”为名称,以“.index”为后缀的文件;再创建一个以“mysql_log_bin”为名称,以 “.000001”为后缀的文件。当mysql服务重新启动一次以“.000001”为后缀的文件会增加一个,并且后缀名加1递增;

log_bin是生成的bin-log的文件名,后缀则是6位数字的编码,从000001开始,按照上面的配置,生成的文件则为: 

      mysql_bin.000001

      mysql_bin.000002


如果日志长度超过了 max_binlog_size的上限(默认是1G)也会创建一个新的日志文件;使用flush logs(mysql命令符)或者执行mysqladmin –u –p flush-logs(windows命令提示符)也会创建一个新的日志文件。


2.基本操作:

由于日志是以二进制方式存储的,不能直接读取,需要使用mysql自带的mysqlbinlog工具来进行查看

mysqlbinlog mysql-bin.000002 -d test

mysqlbinlog有一些选项可以使用,简单说明常用选项:

-d,--database=name :指定数据库名称,只列出指定数据库的操作. 

-D, --disable-log-bin :执行恢复的时候,禁止二进制日志.可以防止同一台MySQL加上-t时进入死循环 

-o,--offset=n :忽略掉日志前n行命令 

-r,--result-file=name :将输出日志到指定文件 

-R, --read-from-remote-server :从一个MySQL服务器上读取二进制 

-s,--short-form :显示简单格式,省略一些信息 

-S, --socket=name  :socket文件连接path. 

-t, --to-last-log  :和-R一起使用,在二进制日志结束的时候并不会停止,而是在MySQL服务器最后生成的binlog结束,如果输出和输入都在一台MySQL上可能会导致死循环. 

--set-charset=char-name :在输出文本格式的时候,在第一行加上set names char-name. 

--start-datetime=# --stop-datetime=# :指定输出起始日期的日志. 

--start-position=# --stop-position=# :指定起始日志的位置.

3.清理:
删除全部二进制日志:

reset master

删除部分日志:

PURGE MASTER LOGS TO & PURGE MASTER LOGS BEFORE

PURGE MASTER LOGS TO 'mysql-bin.000002'命令,是将'000002'编号之前的所有日志进行删除 

PURGE MASTER LOGS BEFORE 'yyyy-mm-dd hh:mm:ss'命令,是将在'yyyy-mm-dd hh:mm:ss'时间之前的所有日志进行删除

设置日志过期时间:
修改my.cnf

expire_log_day=5

这里设置保存5天的日志,超过5天的日志会被自动删除

4.恢复:

完全恢复:

mysqlbinlog mysql-bin.00001|mysql -uroot -p

基于时间点的恢复:
如果误删了一张表,使用完全恢复是没有用的,因为日志里同样也保留着删除的sql语句,所以我们需要恢复到误操作前的状态,然后跳过误操作的语句。
假如我在20:00误删了一张表,可以使用以下语句恢复:

mysqlbinlog --stop-date='2017-03-09 19:59:59' /var/log/mysql-bin.000001 | mysql -uroot -p


跳过误删除的时间点,再执行:

mysqlbinlog --start-date='2017-03-09 20:01:00' /var/log/mysql-bin.000001 | mysql -uroot -p

基于位置点的恢复:
基于位置点的恢复可以得到更为精确的数据。

 

如上图,drop table test这条语句的起始位置是889107,终止位置是889189,那么我们可以使用于以下语句进行恢复:

mysqlbinlog --stop-position='889107' /var/lib/mysql/mysql-bin.000001|mysql -uroot -p 

mysqlbinlog --start-position='889189' /var/lib/mysql/mysql-bin.000001|mysql -uroot -p


有时有可能因为系统版本的问题,以上方法行不通,可以将二进制导出到一个sql文件中,再直接根据sql语句进行恢复,这样导出后log.sql就有sql语句,把语句复制到工具或者phpmyadmin里执行

mysqlbinlog  mysqlbinlog.000001 >log.sql


# mysqlbinlog --start-datetime="2017-03-09 11:25:56" --stop-datetime="2017-03-09 14:20:10" mysql-bin.000001 > /data/test01.log #按时间点导出

# mysqlbinlog --start-position=203  --stop-position=203 mysql-bin.000001 > /data/test02.log #按事件位置导出


简洁文档参考链接:http://yagetang.blog.51cto.com/1780698/1670236

评论
© z0nek | Powered by LOFTER