Chinaunix首页 | 论坛 | 博客
  • 博客访问: 7610260
  • 博文数量: 368
  • 博客积分: 9600
  • 博客等级: 上校
  • 技术积分: 18875
  • 用 户 组: 普通用户
  • 注册时间: 2009-01-01 00:00
文章分类

全部博文(368)

文章存档

2017年(9)

2016年(19)

2015年(3)

2014年(6)

2013年(8)

2012年(78)

2011年(66)

2010年(135)

2009年(44)

分类: Mysql/postgreSQL

2011-07-19 11:08:04

什么是double write:

doulbe write是开辟在innodb tablespace文件上的一块有100个连续page的空间. 注意它是在innodb tablespace文件上. 它的作用是当将数据刷新到 file的时候, 先将数据write + fsync()到double write空间上. 然后在某一个时刻会将数据从double write space写到对应的真正需要写到的page上.

为什么我们会需要double write:

这是因为会存在partial write的问题. partial write是指mysql在将数据写到数据文件的时候, 会出现只写了一半但由于某种原因剩下的数据没有写到innodb file上. 出现这种问题可能是由于系统断电, mysql crash造成的, 而造成这个问题更根本的原因是由于mysql 的page size跟系统文件的page size不一致, 导致在写数据的时候, 系统并不是把整个buffer pool page一次性写到disk上,所以当写到一半时, 系统断电,partial write也就产生了; 如果partial write产生, 会发生什么问题呢? 因为我们知道在flush buffer cache的时候,其实redo log已经写好了. 为什么还需要担心partial write呢? 这是因为mysql在恢复的时候是通过检查page的checksum来决定这个page是否需要恢复的, checksum就是当前这个page最后一个事务的事务号; 如果系统找不到checksum, mysql也就无法对这行数据执行写入操作;

double write的优点是什么?

double write解决了partial write的问题, 它能保证即使double write部分发生了partial write但也能恢复. 另外一个好处就是double write能减少redo log的量, 有了double write, redo log只记录了二进制的变化量, 也就等同于binary log, 而通过前段时间的测试确实发现,在double write关闭的情况下, redo log比binary logs要大;

double write的缺点是什么?

虽然mysql称double write是一个buffer, 但其实它是开在物理文件上的一个buffer, 其实也就是file, 所以它会导致系统有更多的fsync操作, 而我们知道硬盘的fsync性能是很慢的, 所以它会降低mysql的整体性能. 但是并不会降低到原来的50%. 这主要是因为: 1) double write是一个连接的存储空间, 所以硬盘在写数据的时候是顺序写, 而不是随机写, 这样性能更高. 另外将数据从double write buffer写到真正的segment中的时候, 系统会自动合并连接空间刷新的方式, 每次可以刷新多个pages;

double write在恢复的时候是如何工作的?

If there’s a partial page write to the doublewrite buffer itself, the original page will still be on disk in its real location.---如 果是写doublewrite buffer本身失败,那么这些数据不会被写到磁盘,innodb此时会从磁盘载入原始的数据,然后通过innodb的事务日志来计算出正确的数据,重新 写入到doublewrite buffer.When InnoDB recovers, it will use the original page instead of the corrupted copy in the doublewrite buffer. However, if the doublewrite buffer succeeds and the write to the page’s real location fails, InnoDB will use the copy in the doublewrite buffer during recovery. ---如果 doublewrite buffer写成功的话,但是写磁盘失败,innodb就不用通过事务日志来计算了,而是直接用buffer的数据再写一遍.InnoDB knows when a page is corrupt because each page has a checksum at the end; the checksum is the last thing to be written, so if the page’s contents don’t match the checksum, the page is corrupt. Upon recovery, therefore, InnoDB just reads each page in the doublewrite buffer and verifies the checksums. If a page’s checksum is incorrect, it reads the page from its original location.---在恢复的时候,innodb直接比较页面的checksum,如果不对的话,就从硬盘载入原始数据,再由事务日志 开始推演出正确的数据.所以innodb的恢复通常需要较长的时间.

double write是否一定需要?

In some cases, the doublewrite buffer really isn’t necessary—for example, you might want to disable it on slaves. Also, some filesystems (such as ZFS) do the same thing themselves, so it is redundant for InnoDB to do it. You can disable the doublewrite buffer by setting innodb_doublewrite to 0.

如果启用double write以及临控double write的使用

innodb_doublewrite=1 表示启动double write

show status like 'innodb_dblwr%'可以查询double write的使用情况;


转载地址:http://space.itpub.net/7682812/viewspace-669932

阅读(2176) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~