MySQL binlog日志操作详解

Posted yejh

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MySQL binlog日志操作详解相关的知识,希望对你有一定的参考价值。

mysql binlog日志操作详解

MySQL的二进制日志可以说是MySQL最重要的日志了,它记录了所有的DDL和DML(除了数据查询语句)语句,以事件形式记录,还包含语句所执行的消耗的时间,MySQL的二进制日志是事务安全型的。

binlog日志的作用

  1. 其一:MySQL Replication在Master端开启binlog,Mster把它的二进制日志传递给slaves来达到master-slave数据一致的目的。
  2. 其二:自然就是数据恢复了,通过使用mysqlbinlog工具来使恢复数据。
  3. MySQL二进制日志包括两类文件:二进制日志索引文件(文件名后缀为.index)用于记录所有的二进制文件,二进制日志文件(文件名后缀为.00000*)记录数据库所有的DDL和DML(除了数据查询语句)语句事件。

一、开启binlog日志

vim /etc/my.cnf
[mysqld]
log_bin = /data/log/mysql/binlog/mysql-bin.log

重启mysqld服务使配置生效
/etc/init.d/mysqld restart

二、登录mysql服务器,通过mysql的变量配置表,查看二进制日志是否已开启.

mysql> show variables like ‘log_%‘;

+----------------------------------------+----------------------------------------+
| Variable_name                          | Value                                  |
+----------------------------------------+----------------------------------------+
| log_bin                                | ON                                     |
| log_bin_basename                       | /data/log/mysql/binlog/mysql-bin       |
| log_bin_index                          | /data/log/mysql/binlog/mysql-bin.index |
| log_bin_trust_function_creators        | OFF                                    |
| log_bin_use_v1_row_events              | OFF                                    |
| log_builtin_as_identified_by_password  | OFF                                    |
| log_error                              | ./mysql-error.log                      |
| log_error_verbosity                    | 2                                      |
| log_output                             | FILE                                   |
| log_queries_not_using_indexes          | ON                                     |
| log_slave_updates                      | ON                                     |
| log_slow_admin_statements              | ON                                     |
| log_slow_slave_statements              | ON                                     |
| log_statements_unsafe_for_binlog       | ON                                     |
| log_syslog                             | OFF                                    |
| log_syslog_facility                    | daemon                                 |
| log_syslog_include_pid                 | ON                                     |
| log_syslog_tag                         |                                        |
| log_throttle_queries_not_using_indexes | 10                                     |
| log_timestamps                         | SYSTEM                                 |
| log_warnings                           | 1                                      |
+----------------------------------------+----------------------------------------+
21 rows in set (0.02 sec)

三、查看某个binlog日志内容,常用有两种方式:

  1. 使用mysqlbinlog自带查看命令法:
    binlog是二进制文件,普通文件查看器cat more vim 等打开都是乱码,必须使用自带的 mysqlbinlog 命令查看.
[root@mysql ~]# su - mysql 
[mysql@mysql ~]$ mysqlbinlog /data/log/mysql/binlog/mysql-bin.000005
  1. 使用show binlog events 查看binlog日志.
mysql> show binlog events [IN ‘log_name‘] [FROM pos] [LIMIT [offset,] row_count];
选项解析:
               IN ‘log_name‘   指定要查询的binlog文件名(不指定就是第一个binlog文件)
               FROM pos        指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
               LIMIT [offset,] 偏移量(不指定就是0)
               row_count       查询总条数(不指定就是所有行)

截取部分查询结果:

mysql> show binlog events in ‘mysql-bin.000005‘G
*************************** 1. row ***************************
   Log_name: mysql-bin.000005
        Pos: 4
 Event_type: Format_desc
  Server_id: 4294967295
End_log_pos: 123
       Info: Server ver: 5.7.27-log, Binlog ver: 4
*************************** 2. row ***************************
   Log_name: mysql-bin.000005
        Pos: 123
 Event_type: Previous_gtids
  Server_id: 4294967295
End_log_pos: 194
       Info: a775a0a0-37aa-11eb-a07c-000c29292583:1-7
*************************** 3. row ***************************
   Log_name: mysql-bin.000005
        Pos: 194
 Event_type: Gtid
  Server_id: 4294967295
End_log_pos: 259
       Info: SET @@SESSION.GTID_NEXT= ‘a775a0a0-37aa-11eb-a07c-000c29292583:8‘
*************************** 4. row ***************************
   Log_name: mysql-bin.000005                                         ----> 查询的binlog日志文件名
        Pos: 259                                                       ----> pos起始点:
 Event_type: Query                                                     ---->  事件类型
  Server_id: 4294967295                                               ----> 标识是由哪台服务器执行的
End_log_pos: 376                                                       ----> pos结束点:120(即:下行的pos起始点)
       Info: use `test`; create table test (id int,name varchar(10))   ---> 执行的sql语句

这条语句可以将指定的binlog日志文件,分成有效事件行的方式返回,并可使用limit指定pos点的起始偏移,查询条数;

  1. 查询第一个(即mysql-bin.000001)binlog日志:
    mysql> show binlog eventsG
  2. 指定查询 mysql-bin.00005 这个文件:
    mysql> show binlog events in ‘mysql-bin.000005‘G
  3. 指定查询 mysql-bin.000005 这个文件,从pos点:666开始查起:
    mysql> show binlog events in ‘mysql-bin.000005‘ from 666G
  4. 指定查询 mysql-bin.000005 这个文件,从pos点:376开始查起,查询10条
    mysql> show binlog events in ‘mysql-bin.000005‘ from 376 limit 10G
  5. 指定查询 mysql-bin.000005 这个文件,从pos点:376开始查起,偏移2行,查询10条
    mysql> show binlog events in ‘mysql-bin.000005‘ from 376 limit 2,10G

四、 通过全备和binlog日志恢复数据实例:

  1. 假设现在是凌晨1:00,我的计划任务开始执行一次完整的数据库备份:
    将test数据库备份到 /tmp/bak_test.sql 文件中:
[mysql@mysql ~]$ mysqldump -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -lF --log-error=/tmp/myDump.err -B test > /tmp/bak_test.sql

大约过若干分钟,全备份就完成了,我不用担心数据丢失了,因为我有备份了,嘎嘎~~~
由于我使用了-F选项,当备份工作刚开始时系统会刷新log日志,产生新的binlog日志来记录备份之后的数据库“增删改”操作,查看一下:

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+------------------+----------+--------------+------------------+-------------------------------------------+
| mysql-bin.000006 |      194 |              |                  | a775a0a0-37aa-11eb-a07c-000c29292583:1-14 |
+------------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)

也就是说, mysql-bin.000006 是用来记录1:00之后对数据库的所有“增删改”操作

  1. 早9:30上班了,业务的需求会对数据库进行各种“增删改”操作
    比如:创建一个tb1表并插入、修改了数据等等:
mysql>use test;
mysql>CREATE TABLE IF NOT EXISTS `yjh1` (
      `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
      `name` varchar(16) NOT NULL,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

导入数据:

mysql> insert into test.yjh1(name) values(‘DBA‘),(‘CBA‘),(‘NBA‘),(‘UFO‘);

查看数据

mysql> select * from yjh1;
+----+------+
| id | name |
+----+------+
|  1 | DBA  |
|  2 | CBA  |
|  3 | NBA  |
|  4 | UFO  |
+----+------+
4 rows in set (0.00 sec)

中午时分又执行了修改数据操作

mysql> update test.yjh1 set name=‘BBA‘ where id=4;

修改后的结果:

mysql> select * from yjh1;
+----+------+
| id | name |
+----+------+
|  1 | DBA  |
|  2 | CBA  |
|  3 | NBA  |
|  4 | BBA  |
+----+------+
4 rows in set (0.00 sec)

假设此时是下午,脑子一热莫名地执行了一条悲催的SQL语句,整个数据库都没了:
mysql> drop database test;
然后,就没然后了,凌乱一会,开始恢复吧!!
先仔细查看最后一个binlog日志,并记录下关键的pos点,到底是哪个pos点的操作导致了数据库的破坏(通常在最后几步);
备份一下最后一个binlog日志文件:
cp -v /data/log/mysql/binlog/mysql-bin.000006 /tmp/

此时执行一次刷新日志索引操作,重新开始新的binlog日志记录文件,理论说 mysql-bin.000007 这个文件不会再有后续写入了(便于我们分析原因及查找pos点),以后所有数据库操作都会写入到下一个日志文件;

mysql> flush logs;
Query OK, 0 rows affected (0.08 sec)

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+------------------+----------+--------------+------------------+-------------------------------------------+
| mysql-bin.000007 |      194 |              |                  | a775a0a0-37aa-11eb-a07c-000c29292583:1-18 |
+------------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)
  1. 读取binlog日志,分析问题
方式一:使用mysqlbinlog读取binlog日志:
mysqlbinlog /data/log/mysql/binlog/mysql-bin.000006

方式二:登录服务器,并查看(推荐):
以下为末尾片段:

mysql> show binlog events in ‘mysql-bin.000006‘G
...前面行数很多,省略。
*************************** 17. row ***************************
   Log_name: mysql-bin.000006
        Pos: 1238
 Event_type: Gtid
  Server_id: 4294967295
End_log_pos: 1303
       Info: SET @@SESSION.GTID_NEXT= ‘a775a0a0-37aa-11eb-a07c-000c29292583:18‘
*************************** 18. row ***************************
   Log_name: mysql-bin.000006
        Pos: 1303
 Event_type: Query
  Server_id: 4294967295
End_log_pos: 1395
       Info: drop database test
*************************** 19. row ***************************
   Log_name: mysql-bin.000006
        Pos: 1395
 Event_type: Rotate
  Server_id: 4294967295
End_log_pos: 1442
       Info: mysql-bin.000007;pos=4
19 rows in set (0.00 sec)

通过分析,造成数据库破坏的pos点区间是介于 1303--1395 之间,只要恢复到1395前就可。

  1. 现在先把凌晨备份的数据恢复:
    mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -v < /tmp/bak_test.sql
    注: 至此截至当日凌晨(1:00)前的备份数据都恢复了。
    但今天一整天(1:00--现在)的数据肿么办呢?就得从前文提到的 mysql-bin.000007 新日志做文章了......
  2. 从binlog日志恢复数据
恢复语法格式:
# mysqlbinlog mysql-bin.0000xx | mysql -u用户名 -p密码 数据库名
常用选项:
        --start-position=953                    起始pos点
        --stop-position=1437                    结束pos点
        --start-datetime="2017-6-20 13:18:54"   起始时间点
        --stop-datetime="2017-6-20 13:21:53"    结束时间点
        --database=test                       指定只恢复test数据库(一台主机上往往有多个数据库,只限本地log日志)

不常用选项:   
        -u --user=name              Connect to the remote server as username.连接到远程主机的用户名
        -p --password[=name]        Password to connect to remote server.连接到远程主机的密码
        -h --host=name              Get the binlog from server.从远程主机上获取binlog日志
        --read-from-remote-server   Read binary logs from a MySQL server.从某个MySQL服务器上读取binlog日志

小结:实际是将读出的binlog日志内容,通过管道符传递给mysql命令。这些命令、文件尽量写成绝对路径;

  1. 方法1:通过binlog日志mysql-bin.000007直接恢复.
    使用-d参数表示从binlog中只导出test库的数据.
mysqlbinlog mysql-bin.000007 -d test > mysql-bin.sql
然后vim mysql-bin.sql文件,找到误操作的mysql语句,一定要删除.我们这里误操作的sql为drop database test,找到并删除即可.

然后导入/tmp/mysql-bin.sql文件. 
mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -v < /tmp/mysql-bin.sql
  1. 另一种指定位置点导出sql的方法(-r和重定向是一个作用.):
    mysqlbinlog mysqlbin.000020 --start-position=365 --stop-postition=456 -r pos.sql
  2. 方法2:指定pos点恢复数据(部分恢复):

A.指定pos结束点恢复某段时间的数据

@ --stop-position=759 pos结束点
  注:此pos结束点介于“导入实验数据”与更新 name=‘UFO‘之间,这样可以恢复到更改name=‘BBA‘之前的“导入测试数据”

mysqlbinlog --stop-position=759 --database=test mysql-bin.000007 | mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -v test

在另一终端登录查看结果(成功恢复了):

mysql> select * from yjh1;
+----+------+
| id | name |
+----+------+
|  1 | DBA  |
|  2 | CBA  |
|  3 | NBA  |
|  4 | UFO  |
+----+------+
4 rows in set (0.00 sec)

B.指定Pos点区间恢复(部分恢复):

更新name=‘BBA‘这条数据, Info: use `test`; update test.yjh1 set name=‘BBA‘ where id=4

mysqlbinlog --start-position=759 --stop-position=880 --database=test mysql-bin.000007 | mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 test

在另一终端登录查看结果(成功恢复了):

mysql> select * from yjh1;
+----+------+
| id | name |
+----+------+
|  1 | DBA  |
|  2 | CBA  |
|  3 | NBA  |
|  4 | BBA  |
+----+------+
4 rows in set (0.00 sec)

事务区间:INFO信息为两个BEGIN 之间的为按事务区间分 如:Pos: 469 End_log_pos: 759
日志区间:日志区间为Pos: 759 到 End_log_pos: 880
除了用Pos点的办法进行数据恢复,也可以通过指定时间区间进行恢复,按时间恢复需要用mysqlbinlog命令读取binlog日志内容,找时间节点。
例如:
@ --start-datetime="2017-6-20 13:18:54" 起始时间点
@ --stop-datetime="2013-16-20 14:21:53" 结束时间点
通过起始时间段则可以这样恢复数据
mysqlbinlog --start-datetime="2017-6-20 13:18:54" --stop-datetime="2013-16-20 14:21:53" --database=test mysql-bin.000007 | mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -v test

总结:所谓恢复,就是让MySQL将保存在binlog日志中指定段落区间的sql语句逐个重新执行一次而已。

--master-data参数解释:
--master-data
该选项将binlog的位置和文件名追加到输出文件中。

  1. 如果为1,将会输出CHANGE MASTER 命令;
  2. 如果为2,输出的CHANGE MASTER命令前添加注释信息。
    该选项将打开--lock-all-tables选项,除非--single-transaction也被指定(在这种情况下,全局读锁在开始导出时获得很短的时间;其他内容参考下面的--single-transaction选项)。
    该选项自动关闭--lock-tables选项。
--master-data=1
从库: 告诉从库,从主库的那个位置开始同步.

--master-data=2
注释中记录了需要获取的binlog文件和位置点

myisam备份场景:

myisam备份是要锁表,不然数据可能会不一致.
mysqldump -uroot -p123456 -A -B --master-data=2 -x|gzip >/opt/all.sql.gz

innodb备份场景:

mysqldump -uroot -p123456 -A -B --master-data=2 --single-transaction|gzip >/opt/all.sql.gz

innoDB备份示例:

mysqldump --user=root --all-databases --flush-privileges --single-transaction --master-data=1 --flush-logs --triggers --routines --events --hex-blob > /tmp/full_dump.sql

五、常用binlog日志操作命令

  1. 查看所有binlog日志列表
    mysql> show master logs;
  2. 查看master状态,即最后(最新)一个binlog日志的编号名称,及其最后一个操作事件pos结束点(Position)值
    mysql> show master status;
  3. 刷新log日志,自此刻开始产生一个新编号的binlog日志文件
mysql> flush logs;
      注:每当mysqld服务重启时,会自动执行此命令,刷新binlog日志;在mysqldump备份数据时加 -F 选项也会刷新binlog日志;
  1. binlog日志的删除
    binlog的删除可以手工删除或自动删除
    自动删除binlog
    通过binlog参数(expire_logs_days)来实现mysql自动删除binlog
mysql> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       167 |
| mysql-bin.000002 | 531688179 |
| mysql-bin.000003 |      1091 |
| mysql-bin.000004 | 360363501 |
| mysql-bin.000005 |      1798 |
| mysql-bin.000006 |       577 |
| mysql-bin.000007 |      1056 |
| mysql-bin.000008 | 720729027 |
| mysql-bin.000009 |      3010 |
+------------------+-----------+
9 rows in set (0.00 sec)

mysql> show variables like ‘expire_logs_days‘;
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days | 0     |
+------------------+-------+
1 row in set (0.00 sec)

mysql> set global expire_logs_days=14;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like ‘expire_logs_days‘;
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days | 14    |
+------------------+-------+
1 row in set (0.01 sec)

手工删除binlog

mysql> reset master;     //清空所有的binlog日志
mysql> reset slave;      //清空slave的中继日志
mysql> purge master logs before ‘2017-03-30 00:20:00‘;    //删除指定日期以前的日志索引中binlog日志文件
mysql> purge master logs to ‘mysql-bin.000009‘;           //删除指定日志文件的日志索引之前的日志文件
或者直接用操作系统命令直接删除
  1. 显示当前注册的slave的列表。不以--report-host=slave_name选项为开头的slave不会显示在本列表中
    mysql> show slave hosts;

MySQLbinlog的三种日志模式:

1.Statement Level模式:
每一条会修改数据的sql都会记录到master的bin-log中,slave在赋值的时候sql进程会解析成和master端执行过的相同的sql来再次执行.

日志量小,节约IO,提高性能

2.Row Level模式:
日志中会记录成每一行数据被修改的形式,然后在slave端再对相同的数据进行修改

记录下每一行数据修改的细节,解决函数、存储过程等的复制问题.

日志量大.

3.Mixed(混合)模式:
实际就是前两种模式的结合,在Mixed模式下,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式,
也就是在Statement和Row之间选择一种.

修改日志模式的方式:
在配置文件中修改:

log-bin=mysql-bin
binlog_format=‘STATEMENT‘
binlog_format=‘ROW‘
binlog_format=‘MIXED‘

在线修改立即生效方法:
SET SESSION binlog_format = ‘STATEMENT‘;
SET SESSION binlog_format = ‘ROW‘;
SET SESSION binlog_format = ‘MIXED‘;

全局生效:
SET GLOBAL binlog_format = ‘STATEMENT‘;
SET GLOBAL binlog_format = ‘ROW‘;
SET GLOBAL binlog_format = ‘MIXED‘;




































以上是关于MySQL binlog日志操作详解的主要内容,如果未能解决你的问题,请参考以下文章

mysql的binlog日志的binlog_format模式与配置详解

详解:如何恢复MySQL数据库下误删的数据

Mysql binlog详解

MySQL的binlog日志介绍及binlog_format模式与配置详解

MySQL的binlog日志介绍及binlog_format模式与配置详解

mysql的binlog详解