MySQL中的redo log和undo log

MySQL中的redo log和undo log

MySQL日志系统中最重要的日志为 重做日志redo log 和 归档日志bin log ,后者为MySQL Server层的日志,前者为InnoDB存储引擎层的日志。

1 重做日志redo log

1.1 什么是redo log

redo log用于保证事务的持久性,即ACID中的D。

持久性:指一个事务一旦被提交,它对数据库中数据的改变就是永久性的,接下来即使数据库发生故障也不应该对其有任何影响。

redo log有两种类型,分别为物理重做日志和逻辑重做日志。 在InnoDB中redo log大多数情况下是一个物理日志,记录数据页面的物理变化(实际的数据值)。

1.2 redo log的功能

redo log的主要功能是用于数据库崩溃时的数据恢复。

1.3 redo log的组成

redo log可以分为以下两部分

  • 存储在内存中的重做日志缓冲区

  • 存储在磁盘上的重做日志文件

编辑

添加图片注释,不超过 140 字(可选)

1.4 记录redo log的时机

  • 在 完成数据的修改之后,脏页刷入磁盘之前 写入重做日志缓冲区。即先修改,再写入。脏页:内存中与磁盘上不一致的数据(并不是坏的!)

  • 在以下情况下,redo log由重做日志缓冲区写入磁盘上的重做日志文件。redo log buffer的日志占据redo log buffer总容量的一半是 ,将redo log写入磁盘。一个事务提交时 ,他的redo log都刷入磁盘,这样可以保证数据绝不丢失(最常见的情况)。注意这时内存中的脏页可能尚未全部写入磁盘。后台线程定时刷新 ,有一个后台线程每过一秒就将redo log写入磁盘。MySQL关闭时 ,redo log都被写入磁盘。第一种情况和第四种情况一定会执行redo log的写入,第二种情况和第三种情况的执行要根据参数 innodb_flush_log_at_trx_commit 的设定值,在下文会有详细描述。

  • 索引的创建也需要记录redo log。

1.5 一个重做全过程的示例

编辑

添加图片注释,不超过 140 字(可选)

以更新事务为例。

  1. 将原始数据读入内存,修改数据的内存副本。

  2. 生成redo log并写入重做日志缓冲区,redo log中存储的是修改后的新值。

  3. 事务提交时,将重做日志缓冲区中的内容刷新到重做日志文件。

  4. 随后正常将内存中的脏页刷回磁盘。

1.6 持久性的保证

1.6.1 Force Log at Commit机制

Force Log at Commit机制实现了事务的持久性。 在内存中操作时,日志被写入重做日志缓冲区。但在事务提交之前,必须首先将所有日志写入磁盘上的重做日志文件。

为了确保每个日志都写入重做日志文件,必须使用一个fsync系统调用,确保OS buffer中的日志被完整地写入磁盘上的log file。

fsync系统调用:需要你在入参的位置上传递给他一个fd,然后系统调用就会对这个fd指向的文件起作用。fsync会确保一直到写磁盘操作结束才会返回,所以当你的程序使用这个函数并且它成功返回时,就说明数据肯定已经安全的落盘了。所以fsync适合数据库这种程序。

编辑

添加图片注释,不超过 140 字(可选)

1.6.2 innodb_flush_log_at_trx_commit参数

InnoDB提供了一个参数 innodb_flush_log_at_trx_commit 控制日志刷新到磁盘的策略。

  • 当 innodb_flush_log_at_trx_commit 值为1时(默认)。 事务每次提交都必须将log buffer中的日志写入os buffer并调用fsync()写入磁盘中。这种方式即使系统崩溃也不会丢失任何数据,但是因为每次提交都写入磁盘,IO性能较差。

  • 当 innodb_flush_log_at_trx_commit 值为0时。 事务提交时不将log buffer写入到os buffer,而是每秒写入os buffer并调用fsync()写入到log file on disk中。这实际上相当于在内存中维护了一个用户设计的缓冲区,它减少了和os buffer之间的数据传输,有更好的性能。每秒写入磁盘,系统崩溃会丢失1s的数据。

  • 当 innodb_flush_log_at_trx_commit 值为2时。 每次提交都仅写入os buffer,然后每秒调用fsync()将os buffer中的日志写入到log file on disk中。虽然说我们是每秒调用fsync()将os buffer中的日志写入到log file on disk中,但是平时即使不调用fsync,数据也会2自主地逐渐进入磁盘。所以当发生系统崩溃,相比第二种情况,会丢失较少的数据。但同时,由于每次提交都写入os buffer,所以相比第二种情况,性能会差一些,但还是比第一种好的。

  • 无论是哪种情况

  • <
  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值