Mysql日志

MySQL有不同类型的日志文件，用来存储不同类型的日志，分为 二进制日志 、 错误日志 、 通用查询日志和慢查询日志 ，这也是常用的4种。MySQL 8又新增两种支持的日志：中继日志 和 数据定义语句日志 。使用这些日志文件，可以查看MySQL内部发生的事情。
这6类日志分别为：
1.慢查询日志：记录所有执行时间超过long_query_time的所有查询，方便我们对查询进行优化。
2.通用查询日志：记录所有连接的起始时间和终止时间，以及连接发送给数据库服务器的所有指令，对我们复原操作的实际场景、发现问题，甚至是对数据库操作的审计都有很大的帮助。

开启：持久方式
修改my.cnf或者my.ini配置文件来设置。在[mysqld]组下加入log选项，并重启MySQL服务。格式如下：
[mysqld]
general_log=ON 或OFF关闭
general_log_file=[path[filename]] #日志文件所在目录路径，filename为日志文件名
临时方式：
SET GLOBAL general_log=on; # 开启通用查询日志
SET GLOBAL general_log_file=’path/filename’; # 设置日志文件保存位置
SET GLOBAL general_log=off; # 关闭通用查询日志
查看设置后情况：SHOW VARIABLES LIKE ‘general_log%’;
删除：直接删除log文件
再次创建log文件：mysqladmin -uroot -p flush-logs 必须保证日志开启

3.错误日志：记录MySQL服务的启动、运行或停止MySQL服务时出现的问题，方便我们了解服务器的状态，从而对服务器进行维护。
错误日志：在MySQL数据库中，错误日志功能是默认开启的。而且，错误日志无法被禁止 。
mysqld.log 查询：SHOW VARIABLES LIKE ‘log_err%’;
删除直接删文件
重新生成：
1.install -omysql -gmysql -m0644 /dev/null /var/log/mysqld.log
2.mysqladmin -uroot -p flush-logs
4.二进制日志：记录所有更改数据的语句，可以用于主从服务器之间的数据同步，以及服务器遇到故障时数据的无损失恢复。
只记录增删改情况，不记录查询情况（如果记录查询，那就和通用查询日志一样了。Binlog主要用于数据恢复和数据复制，如果记录查询恢复的时候是用不到的）

Sql_log_bin on：增删改记录到日志里 OFF增删改不记录到日志里
查看：show variables like ‘%log_bin%’; 默认开启
每次重启mysql服务器都会重新生成binlog序号递增
持久性配置：
[mysqld]
#启用二进制日志
log-bin=atguigu-bin //改文件名字
binlog_expire_logs_seconds=600 单位秒 默认30天
max_binlog_size=100M //默认1G 最大1G
查看日志：

mysqlbinlog -v “/var/lib/mysql/binlog/atguigu-bin.000002”
上面这种办法读取出binlog日志的全文内容比较多，不容易分辨查看到pos点信息，下面介绍一种更为方便的查询命令：
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 :查询总条数（不指定就是所有行）

Statement
每一条会修改数据的sql都会记录在binlog中。
优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。
Row 5.1.5版本的MySQL才开始支持row level 的复制，它不记录sql语句上下文相关信息，仅保存哪条记录被修改。
优点：row level 的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题。
Mixed
从5.1.8版本开始，MySQL提供了Mixed格式，实际上就是Statement与Row的结合。

恢复数据：
先重新生成一个binlog flush logs
1.根据时间恢复

2.根据position恢复

Binlog删除

删除00003之前的日志
PURGE {MASTER | BINARY} LOGS BEFORE ‘指定日期’

RESET MASTER 删除所有

写入机制：

Binlog在事务提交时也是先存到binlog cache 缓存中。
write和fsync的时机，可以由参数 sync_binlog 控制，默认是 0 。为0的时候，表示每次提交事务都只write，由系统自行判断什么时候执行fsync。虽然性能得到提升，但是机器宕机，page cache里面的binglog 会丢失。

为了安全起见，可以设置为 1 ，表示每次提交事务都会执行fsync，就如同redo log 刷盘流程一样。
最后还有一种折中方式，可以设置为N(N>1)，表示每次提交事务都write，但累积N个事务后才fsync。
Binlog与redolog对比
Redolog它是物理日志，记录内容是“在某个数据页上做了什么修改”属于innodb存储引擎层产生的。
Binlog是逻辑日志，记录内容是语句的原始逻辑，类似于‘给id=2这一行的c字段加1’，属于mysql server层
虽然他们都属于持久化的保证，但是侧重点不同。
Redolog让innodb存储引擎有了崩溃恢复的能力
Binlog保证mysql集群架构的数据一致性。
两阶段提交：
在执行更新语句过程，会记录redo log与binlog两块日志，以基本的事务为单位，redo log在事务执行过程中可以不断写入，而binlog只有在提交事务时才写入，所以redo log与binlog的 写入时机 不一样。
写入时机不同可能导致redolog中保存了最新数据，但是binlog中还未保存

导致主从机的数据不一致

为了解决两份日志之间的逻辑一致问题，InnoDB存储引擎使用两阶段提交方案。

就是redolog先是prepare阶段，写入binlog后再执行commit阶段，如果写入binlog产生异常：发现没到commit阶段 就检查binlog 不存在就回滚事务。

如果在commit阶段异常：发现不是commit，就判断是否存在binlog，存在的话也是可以恢复数据的。（深色框中的逻辑）

5中继日志：用于主从服务器架构中，从服务器用来存放主服务器二进制日志内容的一个中间文件。从服务器通过读取中继日志的内容，来同步主服务器上的操作。
6.数据定义语句日志：记录数据定义语句执行的元数据操作。
除二进制日志外，其他日志都是 文本文件 。默认情况下，所有日志创建于 MySQL数据目录中。