MySQL日志

沉着冷静2024

于 2024-09-11 22:02:55 发布

阅读量516

点赞数 8

分类专栏： MySQL 文章标签： mysql 数据库

本文链接：https://blog.csdn.net/dev1cce/article/details/142151482

版权

MySQL 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

MySQL日志

文章目录

MySQL日志

MySQL三大日志

1.undo log

undo log是InnoDB存储引擎层的日志，实现了事务的原子性，主要用于事务回滚和MVCC。在事务没有提交之前，InnoDB会先记录更新前的数据，记录在undo log中，回滚时利用undo log来回滚。

2.redo log

redo log也是InnoDB存储引擎层的日志，属于物理日志，记录了某个数据页做了什么修改，实现了事务的持久性，主要用于掉电等故障恢复。比如，某个事务提交了，脏页数据还没有刷盘，但是MySQL机器断电了，脏页的数据就丢失了，MySQL重启后通过redo log来把已经提交事务的数据恢复回来。

3.binlog

binlog是Server层的日志，主要用于数据备份和主从复制。在完成一条更新操作后，Server层会生成一条binlog日志，等之后事务提交的时候，会把该事务执行过程中产生的所有binlog统一写入binlog文件。binlog文件是记录了所有数据库表结构变更和表数据修改的日志，不会记录查询类的操作。

binlog的三种格式

STATEMENT(默认)

每条修改数据的SQL都会被记录到binlog中，主从复制中Slave端再根据SQL语句重现。

缺点：STATEMENT有动态函数的问题，比如用了uuid或者now这些函数，主库上执行的结果并不是你在从库中执行的结果，这种随时在变的函数会导致复制的数据不一致。

记录行数据最终被修改成什么样了，不会出现STATEMENT下动态函数出现的问题。

缺点：但是ROW的缺点是每条行变化结果都会被记录。

比如批量执行update语句，更新多少行就会产生多少条记录，使binlog文件过大，而在STATEMENT格式下只会记录一条update语句。

MIXED

包含了STATEMENT和ROW格式，会自动根据情况选择使用哪种格式。

redo log 和 binlog的区别和应用场景

1.适用对象不同

binlog是MySQL的Server层实现的日志，所有存储引擎都可以使用

redo log是InnoDB存储引擎层的日志

2.文件格式不同

binlog有3种格式类型，分别是STATEMENT(默认格式)、ROW、MIXED

redo log是物理日志，记录的是某个数据页做了什么修改，比如XXX表空间中的YYY数据页ZZZ偏移量的地方做了AAA的更新。

3.写入方式不同

binlog是追加写，写满了一个文件，就创建一个新的文件继续写，不覆盖以前的日志，保存的是全量的日志

redo log是循环写，日志的空间大小是固定的，写满就会从头开始写，保存未被刷入磁盘的脏页日志。

4.用途不同

binlog用于备份恢复、主从复制

redo log用于掉电等故障恢复

为什么崩溃恢复不用binlog而用redo log？

binlog是Sever层的日志，不会记录InnoDB存储引擎层中有哪些数据页没有被刷盘，redo log是InnoDB层的日志，可以记录哪些脏页没有被刷盘，崩溃恢复的时候，恢复的粒度更细，可以精确到需要恢复的数据页，而bin log保存的是全量日志，没有办法做到这一点，所以崩溃恢复用的是redo log。

binlog虽然可以恢复，但是恢复性能极差。

redo log如何实现持久化

事务执行过程中更新数据，并不是在事务提交的时候，就把修改的数据刷入磁盘，而是修改Buffer Pool中的数据页，并标记为脏页，后面找合适的时间刷盘。

此时，如果事务提交了，还没有刷盘，数据库发生了宕机，那么就会导致事务修改的数据丢失了。

所以MySQL引入了redo log，redo log保存的内容是物理日志，主要是记录InnoDB对某个数据页的修改操作，当事务提交时，redo log会先刷入磁盘，因为redo log保存了数据页的修改操作，即使脏页数据没有刷盘时数据库发生了党纪，重启后MySQL通过重放redo log，就能恢复未刷盘的脏页，保证了数据的持久化。

redo log还能做什么？

写入redo log的方式使用了追加操作，所以磁盘操作就是顺序写(多个redo log记录在同一个文件中，一起写入磁盘)；而写入数据需要先找到写入位置，然后才写入磁盘，所以磁盘操作是随机写(Buffer poll中修改的多个数据可能在磁盘的不同位置，每次写入一个都需要寻找一次位置，开销很大)。

磁盘的顺序写比随机写高效的多，因此redo log写入磁盘的开销会更小。

为什么顺序写比随机写高效？

因为你在写作业的时候，按顺序一页一页往下写，肯定比每一个字都去找对应页写快的多。

所以说，这是WAL技术的另一个优点：MySQL的写操作从磁盘上的随机写变成了顺序写，提升了语句的执行性能。因为MySQL的写操作不是直接更新的磁盘上，而是先写到日志中，等合适的时间再去更新到磁盘上。

总之，redo log不仅实现了事务的持久性，保证MySQL在任何时间段突然崩溃，重启后之前提交的记录都不丢失，还把写操作从随机写变成了顺序写，提升MySQL写入磁盘的性能。

redo log的三种刷盘策略

单独执行一个更新语句时，InnoDB会自己启动一个事务，在执行更新语句的过程中，生成的redo log先写入到redo log buffer中，然后等待事务提交，再把缓存在redo log buffer中的redo log 按组的方式顺序写到磁盘。

上面的这种刷盘时机是在事务提交的时候，这个是默认的行为。除此之外，还有两种策略，由参数innodb_flush_log_at_trx_commit控制，取值可为0、1、2，默认是1：

参数设置为0：每次事务提交时，还是将redo log留在redo log buffer中，该模式下在事务提交时不会主动触发写入磁盘的操作。

参数设置为1：每次事务提交时，都将缓存在redo log buffer中的redo log直接持久化到磁盘，这样可以保证MySQL异常重启后数据不会丢失。

参数设置为2：每次事务提交时，都是缓存在redo log buffer中的redo log写到redo log文件，注意写入到redo log文件不代表写入磁盘，因为操作系统的文件系统中有个PageCache，PageCache是专门来缓存文件数据的，所以写入redo log文件相当于写入操作系统的文件缓存。

那参数为0、2时，什么时候把数据刷到磁盘上？

0：InnoDB的后台线程每隔1秒，会把缓存缓存在redo log buffer中的redo log，通过write()写入操作系统的PageCache，然后调用fsync()持久化到磁盘。

所以参数为0，MySQL进程崩溃会导致上一秒的事务数据全部丢失。

2：InnoDB的后台线程每隔1秒，调用fsync()将缓存在操作系统中PageCache里的redo log持久化到磁盘。

所以参数为2，比参数为0较为安全，因为MySQL进程崩溃不会丢失数据，只有在操作系统崩溃或系统断电时，上一秒所有事务才可能丢失。

三种策略的安全性和写入性能比较：

安全性：1 > 2 > 0

性能：0 > 2 > 1

所以安全性和性能是不可兼得的。

对于数据安全容忍度低的场景中，参数设置为1
对于可以容忍1秒内数据的丢失的场景中，参数设置为0，这样可以明显减少日志同步到磁盘的IO操作。
安全性和性能最折中的方案就是参数设置为2。

两阶段提交

什么是？为什么？

事务提交后，redo log和binlog都有持久化到磁盘，但是这是两个独立的逻辑，可能出现半成功状态，这样两个日志之间的逻辑就不一致。

比如，id=1这行数据的字段，name原本是张三。然后执行update user set name='李四' where id=1;后，如果持久化redo log和binlog日志时出现了半成功状态，那么：

==如果在将redo log刷入磁盘后，MySQL突然宕机了，而binlog还没来的及写入。==MySQL重启后，通过redo log能将buffer pool中的name字段恢复为李四，但是binlog没有记录这条更新语句，在主从架构中，binlog会被复制到从库，由于binlog丢失了这条更新语句，从库的这一行name仍然是张三，与主库的值不一致。
==如果binlog刷入磁盘后，MySQL宕机了，而redo log还没来的及写入。==由于redo log还没有写入，那么这个事务无效，name字段的值仍然是旧值张三，而binlog记录了这个更新语句，在主从架构中，binlog会被复制到从库，从库执行了这条更新语句，那么从库的这一行name是李四，与主库的值不一致。

所以，在持久化redo log和binlog时，出现半成功状态，就会导致主从库的数据不一致问题。redo log影响主库，binlog影响从库数据，所以redo log和binlog需要保持一致，才能保证主从库的一致。