MySQL重做日志缓冲 - Redo log Buffer

1、查看重做日志配置信息


  • 查看重做日志信息
    mysql> show variables like 'innodb%log%';
    +----------------------------------+-----------+
    | Variable_name                    | Value     |
    +----------------------------------+-----------+
    | innodb_log_buffer_size           | 8388608   | # 日志缓冲池的大小,默认为8M
    | innodb_log_file_size             | 50331648  | # 日志组的大小,默认为5M
    | innodb_log_files_in_group        | 2         | # 日志组的数量,默认为2
    | innodb_log_group_home_dir        | ./        | # 日志组所在的路径,默认为./,表示在数据库的data目录下
    | innodb_mirrored_log_groups       | 1         | # 指定了日志镜像文件组的数量,默认1
    | ......                           | ...       |
    +----------------------------------+-----------+
    12 rows in set (0.00 sec)
    
  • 查看重做日志文件
    [root@centos-7 ~]# ll -ctr /var/lib/mysql
    总用量 176152
    ......
    -rw-rw----. 1 mysql mysql 50331648 6月  26 22:10 ib_logfile1
    -rw-rw----. 1 mysql mysql 50331648 8月  15 23:38 ib_logfile0
    ......
    

2、Mini-Transaction


InnoDB有两个非常重要的日志:undo logredo log
(1)通过undo log可以看到数据较早版本,实现MVCC,或回滚事务等功能。
(2)通过redo log用来保证事务持久性。

Mini-Transaction是用来实现InnoDB的物理逻辑日志的写入和页恢复的。通过Mini-Transaction来保证并发事务操作数据库异常时页的一致性。换言之,Mini-Transaction主要用于innodb redo log和undo log写入,保证两种日志的ACID特性。(注意:是日志的ACID特性)

为了得到页的一致性,Mini-Transaction遵循以下三个协议:

  • The FIX Rules
    (1)修改一个页时需要获得该页的x-latch。
    (2)访问一个页时需要获得该页的s-latch或者x-latch。
    (3)持有该页的latch直到持有者完成对该页的操作。
  • Write-Ahead Log
    (1)持久化一个数据页之前,必须先将内存中相应的日志页持久化。
    (2)每个页有一个LSN,每次页修改需要维护这个LSN。
    (3)当一个页需要写入到持久化设备时,要求内存中小于该页LSN的日志先写入到持久化设备中。
  • Force-log-at-commit
    (1)一个事务可以同时修改了多个页,而Write-AheadLog只能保证单个数据页的一致性,无法保证事务的持久性。
    (2)Force -log-at-commit要求当一个事务提交时,其产生所有的mini-transaction日志必须刷到持久设备中。
    (3)这样即使在页数据刷盘的时候宕机,也可以通过日志进行redo恢复。

3、Redo log Buffer重做日志缓冲


在这里插入图片描述

如上图所示:
(1)InnoDB在缓冲池中变更数据时,会首先将相关变更写入重做日志缓冲中,然后再【按时】,或者当【事务提交】时写入磁盘,这符合Force-log-at-commit原则。
(2)当重做日志写入磁盘后,缓冲池中的变更数据才会依据checkpoint机制择时写入到磁盘中,这符 合WAL原则。

操作系统的文件系统是带有缓存的,当InnoDB向磁盘写入数据时,有可能只是写入到了文件系统的缓存中,没有真正的“落袋为安”。InnoDB提供innodb_flush_log_at_trx_commit属性,可以控制每次事务提交时InnoDB的行为。该参数可以对InnoDB进行性能调优,它涉及了InnoDB对写入效率和数据安全:
在这里插入图片描述

  1. 若属性值为0,事务提交时,不会对重做日志进行写入操作,而是等待主线程按时写入。在该值下,写入效率最高,但是数据安全最低
  2. 若属性值为1,事务提交时,会将重做日志写入文件系统缓存,并且调用文件系统的fsync,将文件系统缓冲中的数据真正写入磁盘存储,确保不会出现数据丢失。在该值下,写入效率最低,但是数据安全最高。一般建议将该属性值设置为1,以获得较高的数据安全性,而且也只有设置为1,才能保证事务的持久性
  3. 若属性值为2,事务提交时,也会将日志文件写入文件系统缓存,但是不会调用fsync,而是让文件系统自己去判断何时将缓存写入磁盘。在该值下,二者都是中等水平
  • 5
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
redolog、binlog和undolog是数据库中常见的日志类型,它们在数据库的事务处理和恢复过程中起着重要的作用。下面是它们的区别和作用: 1. Redo Log重做日志): - Redo Log是用于保证事务的持久性和恢复能力的一种日志记录机制。 - 当数据库执行写操作时,会先将数据写入内存中的Buffer Pool,然后再将修改操作记录到Redo Log中。 - Redo Log的作用是在数据库崩溃或者意外断电等情况下,通过重做日志的回放,将未提交的事务重新应用到数据库中,确保数据的一致性和完整性。 2. Binlog(二进制日志): - BinlogMySQL数据库特有的日志记录机制,用于记录数据库中的所有修改操作。 - Binlog记录了数据库中所有的DDL语句和DML语句,包括对表结构的修改和对数据的增删改操作。 - Binlog的作用是用于数据备份、主从复制和恢复等场景,可以通过回放Binlog来还原数据库到某个特定时间点的状态。 3. Undo Log(撤销日志): - Undo Log是用于实现事务的回滚和MVCC(多版本并发控制)机制的一种日志记录方式。 - 当数据库执行修改操作时,会先将原始数据备份到Undo Log中,然后再进行修改操作。 - Undo Log的作用是在事务回滚或者MVCC读取数据时,通过回滚或者读取Undo Log中的数据,实现数据的一致性和隔离性。 Buffer Pool(缓冲池): - Buffer Pool是数据库中的一个内存区域,用于缓存数据库中的数据页。 - 当数据库执行读操作时,会先在Buffer Pool中查找数据,如果找到则直接返回,如果没有则从磁盘加载到Buffer Pool中。 - Buffer Pool的作用是提高数据库的读取性能,减少磁盘IO操作。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值