阅读 80

MySQL中都有哪些日志文件?

一、序言

首先看一张图:

在这里插入图片描述


上面是MySQL简化版的体系结构图,可以看到自顶向下主要分成了链接池、SQL接口、解析器、查询优化器、缓存、执行引擎、系统文件和日志文件。系统文件和日志文件共同组成了系统文件层,是Mysql实现数据持久化、MVVC、主从同步等功能的重要一层。

Mysql中存在很多不同的日志,例如:错误日志、通用查询日志、二进制日志(Binlog)、Undo/Redo Log、中继日志(Relay Log)、慢查询日志等。

二、错误日志

记录MySQL 运行过程中较为严重的警告和错误信息,以及MySQL每次启动和关闭的详细信息,默认是开启的,可以通过show variables like '%log_error%'查看。

在这里插入图片描述


其中log_error是定义是否启用错误日志的功能和错误日志的存储位置,可以修改/etc/my.cnf配置文件,添加参数log_error=/home/keduw/mysql/mysql.err指定错误日志的路径。


三、通用查询日志

用来记录用户的所有操作,包括启动和关闭 MySQL 服务、更新语句和查询语句等,默认情况下是关闭,可以通过show variables like '%general%'查看。

在这里插入图片描述


一般不开启,会占用大量的磁盘空间。


四、二进制日志(Binlog)

记录了对MySQL数据库执行的更改操作,并且记录了语句的发生时间、执行时长;但是它不记录select、show等不修改数据库的SQL。默认是关闭,可以通过show variables like '%log_bin%'查看是否开启,show binary logs查看日志文件,show variables like '%binlog%'查看参数配置。

在这里插入图片描述


Binlog有两个重要的使用场景:数据库恢复和主从复制,当需要使用对应功能需要开启Binlog日志。可以修改my.cnf或my.ini配置文件,在[mysqld]下面增加log_bin=mysql_bin_log启动。


主从复制的时候,在主库中开启Binlog功能,这样主库就可以把Binlog传递给从库,从库拿到Binlog后实现数据恢复达到主从数据一致性。数据恢复,可以通过mysqlbinlog工具来恢复数据。

Binlog有三种文件记录模式:STATEMENT、ROW和MIXED。

STATEMENT:操作的是执行语句,每一条修改数据的sql都会记录到master的Binlog中,slave在复制的时候会解析成sql语句再次执行,简称sql语句复制。

优点:日志量小,减少磁盘IO,提升存储和恢复速度
缺点:在某些情况下会导致主从数据不一致,比如last_insert_id()、now()等函数。

ROW:操作的是具体的一行数据。日志中会记录每一行数据被修改的情况,然后在slave端对相同的数据进行修改。

优点:能清楚记录每一个行数据的修改细节,能完全实现主从数据同步和数据的恢复。
缺点:批量操作,会产生大量的日志,尤其是alter table会让日志暴涨。

MIXED:以上两种模式的混合使用,一般会使用STATEMENT模式保存binlog,对于STATEMENT模式无法复制的操作使用ROW模式保存binlog,Mysql会根据执行的sql语句选择写入模式。

五、Undo/Redo Log

Undo/Redo Log并不属于Mysql Server的日志,而是属于执行引擎Innodb的日志。

5.1 Undo Log

Undo意为撤销或取消,以撤销操作为目的,返回指定某个状态的操作,Undo Log在事务开始前产生。事务在提交时,并不会立刻删除日志,Innodb会将该事务对应的Undo Log放入到删除列表中,通过后台线程进行回收处理。

数据库事务开始之前,会将要修改的记录存放到Undo Log里,当事务回滚时,可以利用Undo Log,撤销未提交的事务。因此依赖Undo Log可以实现事务的原子性和MVCC(多版本并发控制)。

原子性:事务处理过程中,如果出现了错误或者用户执行了ROLLBACK语句,MySQL可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。

MVCC:事务未提交之前,Undo Log保存了未提交之前的版本数据,Undo Log中的数据可作为数据旧版本快照供其他并发事务进行快照读。事务A手动开启事务,执行更新操作,首先会把更新命中的数据备份到 Undo Buffer 中。事务B手动开启事务,执行查询操作,会读取 Undo 日志数据返回,进行快照读。

在这里插入图片描述

5.2 Redo Log

Redo意为重做,以恢复操作为目的。Redo Log 是为了实现事务的持久性而出现的产物,在事务执行的过程中如果发生异常(比如:数据库崩溃),在重启MySQL服务的时候,根据Redo Log进行重,进而恢复事务的状态。

Undo Log是在事务开启的时候产生,而Redo Log是在事务执行的过程产生。在事务提交时会将产生Redo Log写入Log Buffer,但并不是随着事务的提交就立刻写入磁盘,而是等到事务操作的脏页写入到磁盘之后,Redo Log占用的空间就可以重用(被覆盖写入)。

Redo Log文件内容是以顺序循环的方式写入文件,写满时则回溯到第一个文件,进行覆盖写。


在这里插入图片描述


如上图所示,Redo Log采用双指针进行维护。Write Pos是当前记录的位置,一边写一边后移,写到最后一个文件末尾后就回到0号文件开头;CheckPoint是当前要擦除的位置,也是往后推移并且循环的,擦除记录前要把记录更新到数据文件;

Write Pos和CheckPoint之间还空着的部分,可以用来记录新的操作。如果Write Pos追上CheckPoint,表示写满,这时候不能再执行新的更新,会停下来先擦掉一些记录。如图:W区则是可以写入的区域,R区则是需要刷盘的内容。

5.3 Redo Log相关配置参数

Redo Buffer持久化有三种策略,可通过Innodb_flush_log_at_trx_commit设置,默认是配置1。

0:每秒提交Redo buffer ->OS cache -> flush cache to disk,由后台Master线程每隔 1秒执行一次操作,可能丢失一秒内的事务数据。
1:每次事务提交都会执行Redo buffer ->OS cache -> flush cache to disk,最安全,但是性能最差。
2:每次事务提交执行Redo Buffer -> OS cache,然后由后台Master线程再每隔1秒执行OS cache -> flush cache to disk的操作。

一般建议选择取值2,因为MySQL挂了数据没有损失,整个服务器挂了才会损失1秒的事务提交数据。

六、中继日志(Relay Log)

中继日志主要是MySQL主从同步的时候会用到,下图是主从同步的原理图:


在这里插入图片描述


主从同步主要分成三步:
1:主库将数据库的变更操作记录到Binlog日志文件中
2:从库读取主库中的Binlog日志文件信息写入到从库的Relay Log中继日志中
3:从库读取中继日志信息在从库中进行Replay,更新从库数据信息

可以看到Relay Log中继日志在从库中担当类似中转的作用。可能会觉得从库读取主库中的Binlog日志为什么不直接执行,而是先写入到Relay Log后面由读出来。

看似多余,其实不然。其实我觉得这里还是出于性能和异常的考虑,Replay的操作要比直接文件写入慢得多,毕竟中间还要经过执行引擎的处理,而且如果从库出现异常,有Relay Log做持久化也可以确保从库恢复的时候数据的完整性。

七、慢查询日志

记录所有执行时间超时的查询SQL,默认是10秒,方便于查询缓慢的定位和分析。可以通过show variables like '%slow_query%'查看是否开启和日志的位置,show variables like '%long_query_time%'查看慢查询的阈值。

在这里插入图片描述


六、总结

以上整理了关于MySQL中存在的日志,其实日志存在意义在于定位和记录,其中包括MySQL Server本身的日志,也有Innodb自己的日志,主要前阵子跟一个朋友在讨论这个知识点,感觉有必要做个记录。如果你对文章有什么疑问或者觉得文章有什么问题,欢迎留言/私信交流~



作者:不孤独的字符串
链接:https://www.jianshu.com/p/edda26a5124f


文章分类
后端
版权声明:本站是系统测试站点,无实际运营。本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 XXXXXXo@163.com 举报,一经查实,本站将立刻删除。
相关推荐