MySQL InnoDB的两次写

今天我们来介绍InnoDB存储引擎的第二个特性 - 两次写(doublewrite),如果说插入缓冲是为了提高写 性能的话,那么两次写是为了提高可靠性,牺牲了一点点写性能。

部分写失效

想象这么一个 场景,当数据库正在从内存向磁盘写一个数据页时,数据库宕机,从而导致这个页只写了部分数据,这就是 部分写失效,它会导致数据丢失。这时是无法通过重做日志恢复的,因为重做日志记录的是对页的物理修改 ,如果页本身已经损坏,重做日志也无能为力。

两次写机制

从上面分析我们知道,在部分写 失效的情况下,我们在应用重做日志之前,需要原始页的一个副本,两次写就是为了解决这个问题,下面是 它的原理图:

两次写需要额外添加两个部分:

1)内存中的两次写缓冲(doublewrite buffer),大小为 2MB

2)磁盘上共享表空间中连续的128页,大小也为2MB

其原理是这样的:

1)当刷新缓冲 池脏页时,并不直接写到数据文件中,而是先拷贝至内存中的两次写缓冲区。

2)接着从两次写缓冲 区分两次写入磁盘共享表空间中,每次写入1MB

3)待第2步完成后,再将两次写缓冲区写入数据文件

这样就可以解决上文提到的部分写失效的问题,因为在磁盘共享表空间中已有数据页副本拷贝,如果数据 库在页写入数据文件的过程中宕机,在实例恢复时,可以从共享表空间中找到该页副本,将其拷贝覆盖原有 的数据页,再应用重做日志即可。

其中第2步是额外的性能开销,但由于磁盘共享表空间是连续的,因此 开销不是很大。可以通过参数skip_innodb_doublewrite禁用两次写功能,默认是开启的,强烈建议开启该功 能。

时间: 2025-01-01 14:57:58

MySQL InnoDB的两次写的相关文章

关于ORACLE 和MYSQL INNODB 触发脏数据写的机制对比

首先要说明在ORACLE和INNODB触发checkpoint方面都采用LRU进行管理,并且都有全量检查点和增量检查点一说 在MYSQL中全量检查点叫做sharp checkpoint,增量检查点叫做FUZZY CHECKPOINT, 在ORACLE中更加细化,加入了LRUW链表,并且加入CHECKPOINT-Q列表,两者共同配合完成增量CHECKPOINT,在ORACLE 中DBWR写是按照CHECKPOINT-Q的顺序写的其是LRBA的链表,其触发条件受到MTTR的限制,如果ORACL估计能

MySQL InnoDB 共享表空间和独立表空间

MySQL  InnoDB 共享表空间和独立表空间 官网:https://dev.mysql.com/doc/refman/5.6/en/innodb-multiple-tablespaces.html 前言:学习mysql的时候总是习惯性的和oracle数据库进行比较.在学习mysql InnoDB的存储结构的时候也免不了跟oracle进行比较.Oracle的数据存储有表空间.段.区.块.数据文件:mysql InnoDB的存储管理也类似,但是mysql增加了一个共享表空间和独立表空间的概念:

MySQL InnoDB的插入缓冲

InnoDB存储引擎有三大特性非常令人激动,它们分别是插入缓冲.两次写和自适应哈希,本篇文章先介绍 第一个特性 - 插入缓冲(insert buffer) 在上一篇<MySQL - 浅谈InnoDB存储引擎>中,我们可以 看到在InnoDB的内存中有单独一块叫"插入缓冲"的区域,下面我们详细来介绍它. 非聚集索引写性 能问题 为了阐述非聚集索引写性能问题,我们先来看一个例子: mysql>create table t ( id int auto_increment,

MySQL/InnoDB和Group Commit(2)

今天发现Percona Release的Percona-Server-5-5-18-23-0已经完成了Group Commit工作,而且是用最优雅的方式(移植了MariaDB的实现,而不是workaround),心里难掩激动. 这篇文章接前篇继续介绍一下问题的背景:什么是Group Commit,现在的官方版本Group Commit做到了什么程度? 1. 什么是Group Commit MySQL/InnoDB在做事务的时候使用的日志先行(Write-ahead logging)的方式保证事务

MYSQL InnoDB表锁

InnoDB锁问题 InnoDB与MyISAM的最大不同有两点:一是支持事务(TRANSACTION):二是采用了行级锁.行级锁与表级锁本来就有许多不同之处,另外,事务的引入也带来了一些新问题.下面我们先介绍一点背景知识,然后详细讨论InnoDB的锁问题. 2.并发事务处理带来的问题 相对于串行处理来说,并发事务处理能大大增加数据库资源的利用率,提高数据库系统的事务吞吐量,从而可以支持更多的用户.但并发事务处理也会带来一些问题,主要包括以下几种情况.      更新丢失(ost Update):

MySQL Innodb日志机制深入分析

                            MySQL Innodb日志机制深入分析   1.1. Log & Checkpoint Innodb的事务日志是指Redo log,简称Log,保存在日志文件ib_logfile*里面.Innodb还有另外一个日志Undo log,但Undo log是存放在共享表空间里面的(ibdata*文件).   由于Log和Checkpoint紧密相关,因此将这两部分合在一起分析. 名词解释:LSN,日志序列号,Innodb的日志序列号是一个64位

MySQL Innodb数据库性能实践——合适的表记录数

在实际工作中,经常有同事问道:MySQL Innodb表记录数多大是合适的? 一般的理解肯定是表越大性能越低,但具体低多少呢,是缓慢下降还是急剧下降,是1000万就下降还是1亿才下降呢? 针对这些问题,我做了一下基准测试,基准测试环境如下: [硬件配置] 硬件 配置 CPU Intel(R) Xeon(R) CPU E5620 主频2.40GHz, 物理CPU 2个,逻辑CPU 16个 内存 24G(6块 * 4G  DDR3 1333 REG) 硬盘 300G * 3个,SAS硬盘 15000

MySQL Innodb数据库性能实践

在实际工作中,经常有同事问道:MySQL Innodb表记录数多大是合适的? 一般的理解肯定是表越大性能越低,但具体低多少呢,是缓慢下降还是急剧下降,是1000万就下降还是1亿才下降呢? 针对这些问题,我做了一下基准测试,基准测试环境如下: [硬件配置] 硬件 配置 CPU Intel(R) Xeon(R) CPU E5620 主频2.40GHz, 物理CPU 2个,逻辑CPU 16个 内存 24G(6块 * 4G  DDR3 1333 REG) 硬盘 300G * 3个,SAS硬盘 15000

关于MYSQL INNODB index page header学习和实验总结

关于INNODB  index header 所用到的工具是自己写的mysqlblock和bcview, 我放到了百度云盘 http://pan.baidu.com/s/1num76RJ 供大家下载和使用 普通表空间(及设置了innodb_file_per_table每个表都对应一个idb文件)从第4个块开始通常是innodb的数据页. 前38字节为FILE HEADER 从38字节到74字节为INDEX HEADER,如下: number of directory slot