MySQL常见日志
Error log 错误日志
General query log 普通查询日志
Slow query log 慢查询日志
Binary log 二进制日志
下面重点描述二进制日志 Binary log ，Binary log 简写为 binlog
其作用：
1、增量备份(只备份新增的)
2、主从复制
在MySQL5.7中binlog默认不开启，现在我们去看下
mysql> show variables like '%log_bin%';
+---------------------------------+-------+
| Variable_name | Value |
+---------------------------------+-------+
| log_bin | OFF |
| log_bin_basename | |
| log_bin_index | |
| log_bin_trust_function_creators | OFF |
| log_bin_use_v1_row_events | OFF |
| sql_log_bin | ON |
+---------------------------------+-------+
6 rows in set (0.00 sec)
mysql>
可以看出 log_bin 为OFF是没有开启。下面开启binlog日志，退出mysql,在终端编辑mysql的配置文件，添加以下配置
[root@master /]# vi /etc/my.cnf
#start binlog
server-id=1
log-bin=/var/lib/mysql/mysql-bin
注意：sever-id一个节点只能有一个，添加后重启mysql服务。
[root@master /]# service mysqld restart
再次查看binlog日志是否开启
1、直接在刚刚配置的目录下查看
看到mysql-bin.000001就说明binlog日志已经开启
其中：mysql-bin.000001的.000001指的是第一个mysql的二进制日志的数据文件，mysql-bin.index指的是二进制日志的索引文件。
2、进入到mysql输入
mysql> show variables like '%log_bin%';
+---------------------------------+--------------------------------+
| Variable_name | Value |
+---------------------------------+--------------------------------+
| log_bin | ON |
| log_bin_basename | /var/lib/mysql/mysql-bin |
| log_bin_index | /var/lib/mysql/mysql-bin.index |
| log_bin_trust_function_creators | OFF |
| log_bin_use_v1_row_events | OFF |
| sql_log_bin | ON |
+---------------------------------+--------------------------------+
6 rows in set (0.00 sec)
看到log_bin为NO说明binlog日志已经开启。其中 log_bin_basename就指的是你mysql-bin.000001。log_bin_index 指的是mysql-bin.index文件。
对于刚开启的binlog日志文件，它的索引文件了里应只有一条索引记录，现在我们去看下
[root@master /]# cat /var/lib/mysql/mysql-bin.index
/var/lib/mysql/mysql-bin.000001
[root@master /]#
可以看到只记录了一个索引。现在我们去看下binog日志文件的内容
方法一：终端下查看
[root@master mysql]# cat mysql-bin.000001
_þbinJ]w{5.7.27-logJ]8
发现内容很奇怪，要注意此时在Linux终端无法用cat命令查看mysql-bin.000001文件，因为该文件是一个二进制文件，cat命令无法解析二进制，因此应当用专有命令去查看，输入
[root@master mysql]# mysqlbinlog mysql-bin.000001
内容为：
[root@master mysql]# mysqlbinlog mysql-bin.000001
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#190927 7:30:26 server id 1 end_log_pos 123 CRC32 0xbf35e26a Start: binlog v 4, server v 5.7.27-log created 190927 7:30:26 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
EkqNXQ8BAAAAdwAAAHsAAAABAAQANS43LjI3LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAASSo1dEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AWriNb8=
'/*!*/;
# at 123
#190927 7:30:26 server id 1 end_log_pos 154 CRC32 0xcb265d2a Previous-GTIDs
# [empty]
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*/;
[root@master mysql]#
方法二：mysql中查看
mysql> show binlog events;
首先查案所有记录在案的日志大体信息
要查看具体某一日志文件信息时后面跟上文件名即可
mysql> show binlog events in 'fileName';
为了初步解释说明binlog日志文件，现在我们创建一个数据库和表并插入一条数据，
mysql> create database test;
Query OK, 1 row affected (0.00 sec)
mysql> use test;
Database changed
mysql> create table suer( id int, name varchar(10));
Query OK, 0 rows affected (0.13 sec)
mysql> insert into suer values(1,'bear');
Query OK, 1 row affected (0.10 sec)
mysql> insert into suer values(1,'bear');
Query OK, 1 row affected (0.10 sec)
上述过程中有几个输入错误的语句，这里我直接把正确的写了上去。此时我们再次查看日志文件信息
可以发现多出了一些日志信息，即binlog日志可以记录我们的所有操作。
接下来我们来具体分析下binlog日志文件
首先注意到下图的Pos列中操作之前多了154到720等信息，这里我们针对一个来进行分析，我们这里选择219
在终端打开binlog日志文件
[root@master mysql]# mysqlbinlog mysql-bin.000001
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#190927 7:30:26 server id 1 end_log_pos 123 CRC32 0xbf35e26a Start: binlog v 4, server v 5.7.27-log created 190927 7:30:26 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
EkqNXQ8BAAAAdwAAAHsAAAABAAQANS43LjI3LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAASSo1dEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AWriNb8=
'/*!*/;
# at 123
#190927 7:30:26 server id 1 end_log_pos 154 CRC32 0xcb265d2a Previous-GTIDs
# [empty]
# at 154
#190927 8:07:23 server id 1 end_log_pos 219 CRC32 0x36668b6d Anonymous_GTID last_committed=0 sequence_number=1 rbr_only=no
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 219
#190927 8:07:23 server id 1 end_log_pos 313 CRC32 0xa2c769a7 Query thread_id=3 exec_time=0 error_code=0
SET TIMESTAMP=1569542843/*!*/;
SET @@session.pseudo_thread_id=3/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
create database test
/*!*/;
# at 313
#190927 8:09:13 server id 1 end_log_pos 378 CRC32 0x483ce4d2 Anonymous_GTID last_committed=1 sequence_number=2 rbr_only=no
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 378
#190927 8:09:13 server id 1 end_log_pos 496 CRC32 0x5432a21d Query thread_id=3 exec_time=0 error_code=0
use `test`/*!*/;
SET TIMESTAMP=1569542953/*!*/;
create table suer( id int, name varchar(10))
/*!*/;
# at 496
#190927 8:12:26 server id 1 end_log_pos 561 CRC32 0x0c142d46 Anonymous_GTID last_committed=2 sequence_number=3 rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 561
#190927 8:12:26 server id 1 end_log_pos 633 CRC32 0x36aa3246 Query thread_id=3 exec_time=0 error_code=0
SET TIMESTAMP=1569543146/*!*/;
BEGIN
/*!*/;
# at 633
#190927 8:12:26 server id 1 end_log_pos 683 CRC32 0x784f3f10 Table_map: `test`.`suer` mapped to number 110
# at 683
#190927 8:12:26 server id 1 end_log_pos 728 CRC32 0xac344fee Write_rows: table id 110 flags: STMT_END_F
BINLOG '
6lONXRMBAAAAMgAAAKsCAAAAAG4AAAAAAAEABHRlc3QABHN1ZXIAAgMPAgoAAxA/T3g=
6lONXR4BAAAALQAAANgCAAAAAG4AAAAAAAEAAgAC//wBAAAABGJlYXLuTzSs
'/*!*/;
# at 728
#190927 8:12:26 server id 1 end_log_pos 759 CRC32 0xff379272 Xid = 20
COMMIT/*!*/;
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*/;
我们找到219
我们把219单独提取出来分析
# at 219
#190927 8:07:23 server id 1 end_log_pos 313 CRC32 0xa2c769a7 Query thread_id=3 exec_time=0 error_code=0
SET TIMESTAMP=1569542843/*!*/;
SET @@session.pseudo_thread_id=3/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
create database test
/*!*/;
首先像这样单独的一节我们称之为一个 事件，每个事件由两部分组成，时间头 和 事件体
事件头中主要记录了一些此次事件操作的起始id、时间戳、server id、终止id(end_log_pos 313)等信息。
事件体中记录一些该事件操作的其它信息。
Binlog日志的操作
现在我们重启mysql服务，然后再查看
发现重启服务后binlog日志数据文件多了一个【每次重启mysql服务后，服务器会调用flash logs来创建一个新的binlog日志】。想象一个场景，第二天重启服务后，当天的操作日志信息都在.000002这个文件中，当突然发现昨天有个操作是错误的，这是只需在.000001文件中进行造作即可，方便管理操作。
1、flash logs 刷新日志文件，产生一个新的日志文件
2、show binlog events in 'fileName';查看指定日志文件信息
3、show master status查看当前操作记录在那个日志文件里
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000002 | 154 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
可以看出当前操作记录在mysql-bin.000002文件中。
4、show master logs; 查看一共记录了多少个日志
法一：
mysql> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 782 |
| mysql-bin.000002 | 154 |
+------------------+-----------+
2 rows in set (0.00 sec)
法二：直接查看mysql-bin.index[索引文件]文件内容
[root@master mysql]# cat mysql-bin.index
/var/lib/mysql/mysql-bin.000001
/var/lib/mysql/mysql-bin.000002
5、reset master 清空所有binlog数据日志文件(不建议操作)
binlog数据恢复
首先我们忘suer表里插入几条数据
mysql> select * from suer;
+------+--------+
| id | name |
+------+--------+
| 1 | bear |
| 2 | flower |
| 3 | key |
| 4 | linux |
+------+--------+
然后删除id>=2的数据
mysql> delete from suer where id >=2;
Query OK, 3 rows affected (0.41 sec)
mysql> select * from suer;
+------+------+
| id | name |
+------+------+
| 1 | bear |
+------+------+
1 row in set (0.00 sec)
mysql>
恢复数据
[root@master mysql]# mysqlbinlog mysql-bin.000002 | mysql -uroot -p
登录mysql
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from suer;
+------+--------+
| id | name |
+------+--------+
| 1 | bear |
| 2 | flower |
| 3 | key |
| 4 | linux |
+------+--------+
4 rows in set (0.00 sec)
mysql>
可以看到，刚刚删除的数据已经恢复。
当想恢复指数据时：需要查看binlog日志中想要恢复的数据的起始位置和终止位置，比如219-421。这时加入参数
mysqlbinlog mysql-bin.000002 --start-position 219 --stop-position 421 | mysql -uroot -p
查看binlog帮助文档
[root@master mysql]# mysqlbinlog