MySQL中都有哪些日志文件? |
您所在的位置:网站首页 › 数据查询包括什么内容 › MySQL中都有哪些日志文件? |
一、序言
首先看一张图:
Mysql中存在很多不同的日志,例如:错误日志、通用查询日志、二进制日志(Binlog)、Undo/Redo Log、中继日志(Relay Log)、慢查询日志等。 二、错误日志记录MySQL 运行过程中较为严重的警告和错误信息,以及MySQL每次启动和关闭的详细信息,默认是开启的,可以通过show variables like '%log_error%'查看。 用来记录用户的所有操作,包括启动和关闭 MySQL 服务、更新语句和查询语句等,默认情况下是关闭,可以通过show variables like '%general%'查看。 记录了对MySQL数据库执行的更改操作,并且记录了语句的发生时间、执行时长;但是它不记录select、show等不修改数据库的SQL。默认是关闭,可以通过show variables like '%log_bin%'查看是否开启,show binary logs查看日志文件,show variables like '%binlog%'查看参数配置。 主从复制的时候,在主库中开启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 LogUndo/Redo Log并不属于Mysql Server的日志,而是属于执行引擎Innodb的日志。 5.1 Undo LogUndo意为撤销或取消,以撤销操作为目的,返回指定某个状态的操作,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 日志数据返回,进行快照读。 Redo意为重做,以恢复操作为目的。Redo Log 是为了实现事务的持久性而出现的产物,在事务执行的过程中如果发生异常(比如:数据库崩溃),在重启MySQL服务的时候,根据Redo Log进行重,进而恢复事务的状态。 Undo Log是在事务开启的时候产生,而Redo Log是在事务执行的过程产生。在事务提交时会将产生Redo Log写入Log Buffer,但并不是随着事务的提交就立刻写入磁盘,而是等到事务操作的脏页写入到磁盘之后,Redo Log占用的空间就可以重用(被覆盖写入)。 Redo Log文件内容是以顺序循环的方式写入文件,写满时则回溯到第一个文件,进行覆盖写。 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主从同步的时候会用到,下图是主从同步的原理图: 可以看到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自己的日志,主要前阵子跟一个朋友在讨论这个知识点,感觉有必要做个记录。如果你对文章有什么疑问或者觉得文章有什么问题,欢迎留言/私信交流~ |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |