MySQL之doublewrite

在这里插入图片描述

看文档redo log不是必须的 如果doublewrite写完了 原始数据写的时候失败了可以直接用doublewrite的数据 如果doublewrite都没写完 这时候原始数据肯定是对的 原始数据用redo log恢复就可以了
一、脏页刷盘风险

关于IO的最小单位:

1、数据库IO的最小单位是16K(MySQL默认,oracle是8K)

2、文件系统IO的最小单位是4K(也有1K的)

3、磁盘IO的最小单位是512字节

因此,存在IO写入导致page损坏的风险:
在这里插入图片描述
二、doublewrite:两次写

提高innodb的可靠性,用来解决部分写失败(partial page write页断裂)。

1、Double write解决了什么问题

一个数据页的大小是16K,假设在把内存中的脏页写到数据库的时候,写了2K突然掉电,也就是说前2K数据是新的,后14K是旧的,那么磁盘数据库这个数据页就是不完整的,是一个坏掉的数据页。redo只能加上旧、校检完整的数据页恢复一个脏块,不能修复坏掉的数据页,所以这个数据就丢失了,可能会造成数据不一致,所以需要double write。

2、使用情景

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

3、double write工作流程

doublewrite由两部分组成,一部分为内存中的doublewrite buffer,其大小为2MB,另一部分是磁盘上共享表空间(ibdata x)中连续的128个页,即2个区(extent),大小也是2M。

1、当一系列机制触发数据缓冲池中的脏页刷新时,并不直接写入磁盘数据文件中,而是先拷贝至内存中的doublewrite buffer中;

2、接着从两次写缓冲区分两次写入磁盘共享表空间中(连续存储,顺序写,性能很高),每次写1MB;

3、待第二步完成后,再将doublewrite buffer中的脏页数据写入实际的各个表空间文件(离散写);(脏页数据固化后,即进行标记对应doublewrite数据可覆盖)

4、doublewrite的崩溃恢复

如果操作系统在将页写入磁盘的过程中发生崩溃,在恢复过程中,innodb存储引擎可以从共享表空间的doublewrite中找到该页的一个最近的副本,将其复制到表空间文件,再应用redo log,就完成了恢复过程。

因为有副本所以也不担心表空间中数据页是否损坏。

Q:为什么log write不需要doublewrite的支持?

A:因为redolog写入的单位就是512字节,也就是磁盘IO的最小单位,所以无所谓数据损坏。

三、doublewrite的副作用
在这里插入图片描述
1、double write带来的写负载

1、double write是一个buffer, 但其实它是开在物理文件上的一个buffer, 其实也就是file, 所以它会导致系统有更多的fsync操作, 而硬盘的fsync性能是很慢的, 所以它会降低mysql的整体性能。

2、但是,doublewrite buffer写入磁盘共享表空间这个过程是连续存储,是顺序写,性能非常高,(约占写的%10),牺牲一点写性能来保证数据页的完整还是很有必要的。

2、监控double write工作负载

mysql> show global status like ‘%dblwr%’;
±---------------------------±------+
| Variable_name | Value |
±---------------------------±------+
| Innodb_dblwr_pages_written | 7 |
| Innodb_dblwr_writes | 3 |
±---------------------------±------+
2 rows in set (0.00 sec)
  关注点:Innodb_dblwr_pages_written / Innodb_dblwr_writes

开启doublewrite后,每次脏页刷新必须要先写doublewrite,而doublewrite存在于磁盘上的是两个连续的区,每个区由连续的页组成,一般情况下一个区最多有64个页,所以一次IO写入应该可以最多写64个页。

而根据以上系统Innodb_dblwr_pages_written与Innodb_dblwr_writes的比例来看,大概在3左右,远远还没到64(如果约等于64,那么说明系统的写压力非常大,有大量的脏页要往磁盘上写),所以从这个角度也可以看出,系统写入压力并不高。

3、关闭double write适合的场景

1、海量DML

2、不惧怕数据损坏和丢失

3、系统写负载成为主要负载

mysql> show variables like ‘%double%’;
±-------------------±------+
| Variable_name | Value |
±-------------------±------+
| innodb_doublewrite | ON |
±-------------------±------+
1 row in set (0.04 sec)
  作为InnoDB的一个关键特性,doublewrite功能默认是开启的,但是在上述特殊的一些场景也可以视情况关闭,来提高数据库写性能。静态参数,配置文件修改,重启数据库。

4、为什么没有把double write里面的数据写到data page里面呢?

1、double write里面的数据是连续的,如果直接写到data page里面,而data page的页又是离散的,写入会很慢。

2、double write里面的数据没有办法被及时的覆盖掉,导致double write的压力很大;短时间内可能会出现double write溢出的情况。

  • 0
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
处理一下出现的日志 Plugin 'FEDERATED' is disabled. 2017-11-15 19:23:46 16c0 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator. 2017-11-15 19:23:46 1404 [Note] InnoDB: Using atomics to ref count buffer pool pages 2017-11-15 19:23:46 1404 [Note] InnoDB: The InnoDB memory heap is disabled 2017-11-15 19:23:46 1404 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions 2017-11-15 19:23:46 1404 [Note] InnoDB: Memory barrier is not used 2017-11-15 19:23:46 1404 [Note] InnoDB: Compressed tables use zlib 1.2.3 2017-11-15 19:23:46 1404 [Note] InnoDB: Not using CPU crc32 instructions 2017-11-15 19:23:46 1404 [Note] InnoDB: Initializing buffer pool, size = 9.0G 2017-11-15 19:23:46 1404 [Note] InnoDB: Completed initialization of buffer pool 2017-11-15 19:23:46 1404 [Note] InnoDB: Highest supported file format is Barracuda. 2017-11-15 19:23:46 1404 [Note] InnoDB: Log scan progressed past the checkpoint lsn 9219742510 2017-11-15 19:23:46 1404 [Note] InnoDB: Database was not shutdown normally! 2017-11-15 19:23:46 1404 [Note] InnoDB: Starting crash recovery. 2017-11-15 19:23:46 1404 [Note] InnoDB: Reading tablespace information from the .ibd files... 2017-11-15 19:23:46 1404 [Note] InnoDB: Restoring possible half-written data pages 2017-11-15 19:23:46 1404 [Note] InnoDB: from the doublewrite buffer... InnoDB: Doing recovery: scanned up to log sequence number 9219763629 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 0 row operations to undo InnoDB: Trx id counter is 275040768 2017-11-15 19:23:47 1404 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值