前言
MySQL 经常出现启动错误或者执行错误等等，这个时候我们需要查询error日志
在数据库使用中，经常会出现需要恢复数据的情况，MySQL如果需要恢复数据的话需要开启binlog（二进制日志）。
Error Log
错误日志默认设置如下：
1. error log 默认路径在数据文件下。
2. error log 默认文件名为主机名.err，例如：iZm5e5v2zi93osbr5z21fvZ.err。
自定义设置文件名和路径：
打开MySQL的配置文件 vim /etc/my.cnf 加入如下配置
log_error=/usr/local/mysql/log/mysql.log
Bin Log
1. 配置
mysql 8.0 版本之前，默认不开启，生成建议开启。
my.cnf 文件夹下面参数设置。
server_id = 5 ; # 服务编号，5.7必须要。
log_bin=/data/binlog/mysql-bin # binlog 日志存放目录+前缀，日志文件名例如：mysql-bin.0001 ，注意目录需要提前存在。
sync_binlog=1 # binlog 刷写的策略。1：表示提交只有立即写入磁盘。
binlog_format=row # binlog的记录格式为row模式
重启MySQL之后再对应目录下可以看到如下日志：
其中 mysql-bin.index 是日志索引文件。
重要：binlog 日志建议和数据盘分开存放，防止硬盘坏了的情况。
mysql> select @@log_bin_basename; -- 查询bin_log 存放位置
mysql> select @@log_bin; -- 查询bin_log 是否开启 1：开启
2. 说明
1. binlog 记录内容
binlog 会记录下以下操作：
DDL 操作表结构，字段的语句。
DCL 权限等一些控制语句。
DML 操作表的语句（insert,update,delete），并且是已经提交的，未提交的不会记录
DDL 和 DCL 记录的是你写了啥就记录啥。 DML语句记录方式可以通过参数控制
mysql> select @@binlog_format; -- 5.7 默认ROW, statement:写啥记啥，ROW:记录数据页变化，mixed:混合前两种记录
statement : 可读性高（文本），日志量少，不够严谨（遇到获取当前日期的时候，因为语句是故障时执行的，但是后续通过这种方式无法获取当时的时间点）。
row : 可读性低（二进制），日志量大，严谨。
3. bin log 查看
mysql> show binary logs; -- 查询mysql存在的binlog日志文件
mysql> show master status; -- 查询现在正在使用binlog 日志文件
mysql> show binlog events in 'mysql-bin.000002'; -- 查看当前被使用的binlog 信息
mysqlbinlog mysql-bin.000002 -- 使用mysqlbinlog 命令查看binlog 日志。
mysqlbinlog --base64-output=decode-rows -vvv mysql-bin.000002 -- 该命令可以翻译binlog 下的DML 操作语句，只能用于查看。
mysql> flush logs -- 创建新的日志。后续binlog 就从这个新日志开始
查询日志就可以看到新的日志：
4. 通过binlog 恢复数据
模拟误操作的情况：第9步删除和第13步的drop。
(0) drop database if exists testdb ;
(1) create database testdb charset utf8;
(2) use testdb;
(3) create table t1 (id int);
(4) insert into t1 values(1),(2),(3);
(5) insert into t1 values(4),(5),(6);
(6) commit
(7) update t1 set id=30 where id=3;
(8) commit;
(9) delete from t1 where id=4;
(10)commit;
(11)insert into t1 values(7),(8),(9);
(12)commit;
(13)drop database testdb;
我们要恢复第9步删除和第13步的drop 操作之前的数据
截取binlog 日志，找到起点和终点。 我现在要恢复到drop 操作前： 找到开始位置点和结束位置点， 我需要的 383 到 2048 ，下面的语句就是将日志转化成语句。
mysqlbinlog --start-position=383 --stop-position=2048 /usr/local/mysql/binlog/mysql-bin.000003 > /usr/local/mysql/bin2.sql
还有一种通过实践截取的方式：
mysqlbinlog --start-datetime=200812 21:08:26 --stop-datetime=200912 21:09:09 mysql-bin.000001 mysql-bin.000002 mysql-bin.000003 > /usr/local/mysql/bin2.sql
接下来就是导入SQL文件即可，重点因为这是恢复，所以我们不需要他再记录binlog日志，故导入SQL文件前，先临时关闭binlog. 操作如下：
mysql> set sql_log_bin = 0; -- 关闭binlog日志
mysql> source /usr/local/mysql/bin2.sql -- 导入sql脚本（通过binlog截取出来的）
mysql> set sql_log_bin = 1; -- 开启binlog日志
指定数据库的binlog导出（-d 数据库名）：
mysqlbinlog -d testdb --start-position=383 --stop-position=2048 /usr/local/mysql/binlog/mysql-bin.000003 > /usr/local/mysql/bin2.sql
binlog实际场景中的运用方式：
binlog 主要是配和备份数据一起恢复数据库， 先通过备份数据库恢复到比如一个星期前的数据，然后剩下的数据由binlog恢复。
5. binlog 维护命令
mysql> select @@max_binlog_size;
binlog 不要直接删除物理文件：
mysql> select @@expire_logs_days; -- binlog保存天数，0特殊表示永久保存。
mysql> purge binary logs to 'mysql-bin.000002'; -- 删除binlog日志到mysql-bin.000002，也就是把mysql-bin.000001 删除。
purge binary logs before now() - interval 3 day; 根据时间删除，删除3天前的日志。
mysql> reset master; -- 全部删除，操作不建议使用，主从必然会down。
6. binlog(GTID)
GTID(Global Transaction ID) :
mysql> select @@session.gtid_next = 'anonymous'; -- GTID是否开启，1开启
GTID 定义
GTID = source_id ：transaction_id 例如：7E11FA47-31CA-19E1-9E56-C43AA21293967:29
gtid-mode=on -- 和参数enforce-gtid-consistency一起开启gtid功能。
enforce-gtid-consistency=true -- 见gtid-mode说明
开启GTID之后对数据库的操作会记录GTID
binlog日志中也记录了GTID。
mysql> select @@server_uuid; -- 查看gtid的uuid
数据文件目录下会存在一个文件：
/usr/local/mysql/mysql-5.7.22-linux-glibc2.12-x86_64/data/auto.cnf 里面也记录了server_uuid。
通过案例说明如何使用gtid恢复数据
(1) create database gtiddb charset utf8;
(2) use gtiddb ;
(3) create table t1 (id int);
(4) insert into t1 values(1),(2),(3);
(5) insert into t1 values(4),(5),(6);
(6) commit
(7) update t1 set id=30 where id=3;
(8) commit;
(9) delete from t1 where id=4;
(10)commit;
(11)insert into t1 values(7),(8),(9);
(12)commit;
(13)glush logs;
(14)insert into t1 values(10);
(15)drop database gtiddb ;
第13步模拟切换日志， 第15步误操作。 需要恢复到第14步。
根据（show binlog events in 'mysql-bin.000002';） 找到恢复数据的gtid起点：8993a5f5-2921-11ea-a866-00163e046b75:2 终点：8993a5f5-2921-11ea-a866-00163e046b75:9
下面是截取命令，我们取2到9 的gtid数据，并且排除7，delete 我们也不要删除。
mysqlbinlog --include-gtids='8993a5f5-2921-11ea-a866-00163e046b75:2-9' --exclude-gtids='8993a5f5-2921-11ea-a866-00163e046b75:7' mysql-bin.000002 mysql-bin.000003 > /usr/local/mysql/gtid.sql
恢复操作和之前是一样的
mysql> set sql_log_bin = 0; -- 关闭binlog日志
mysql> source /usr/local/mysql/gtid.sql; -- 导入sql脚本（通过binlog截取出来的）
mysql> set sql_log_bin = 1; -- 开启binlog日志
上述操作你会发现恢复不了数据，那是为什么呢？
重点：GTID的幂等性：开启GTID后,MySQL恢复Binlog时,重复GTID的事务不会再执行。 那要如何处理呢？
截取日志的时候过滤掉gtid 需要在截取命令中加入参数 --skip-gtids。
mysqlbinlog --skip-gtids --include-gtids='8993a5f5-2921-11ea-a866-00163e046b75:2-9' --exclude-gtids='8993a5f5-2921-11ea-a866-00163e046b75:7' mysql-bin.000002 mysql-bin.000003 > /usr/local/mysql/gtid.sql
小结：binlog 重要性不言而喻，后续真正备份恢复中也需要binlog日志，才能达到真正的恢复如初。
Slow Log
作用：记录慢SQL语句的日志,定位低效SQL语句的工具日志，默认不开启。
配置：
mysql> select @@slow_query_log; -- 控制慢日志是否开启的开关0：不开启，1：开启
mysql> select @@slow_query_log_file; -- 慢日志存放的位置
mysql> select @@long_query_time; --设置时间规则执行多少时间算慢。
mysql> select @@log_queries_not_using_indexes; -- 开启是否记录不走索引的语句，0:关，1：开
案例：准备100万数据量的表。然后执行查询语句，然后查看日志
当你日志庞大的时候，你会发现vi 看不方便，mysql给我们提供了方便看这个信息的命令：
mysqldumpslow -s c -t 5 /usr/local/mysql/mysql-5.7.22-linux-glibc2.12-x86_64/data/iZm5e5v2zi93osbr5z21fvZ-slow.log -- c 表示数量，-t 5 显示前5条。
扩展可以实现：更加方便的展示slowlog日志信息。
Anemometer基于pt-query-digest将MySQL慢查询可视化。
总结
会看MySQL日志是非常重要的，并且MySQL提供的日志非常重要，我们需要能够理解日志原理，更好为MySQL的数据安全，性能提供帮助。