页断裂(partial write)与doublewrite技术

      mysql double write (二次写)是mysql innodb存储引擎的一个重要特性,本人这两天翻阅了相关的资料,结合自己已有的知识,说说自己对double write的理解,供各位看官参考。

页断裂(partial write)

double write技术innodb为解决页断裂(partial write)问题而生,所谓页断裂是数据库宕机时(OS重启,或主机掉电重启),数据库页面只有部分写入磁盘,导致页面出现不一致的情况。数据库,OS和磁盘读写的基本单位是块,也可以称之为(page size)block size。我们知道数据库的块一般为8K,16K;而OS的块则一般为4K;IO块则更小,linux内核要求IO block size<=OS block size。磁盘IO除了IO block size,还有一个概念是扇区(IO sector),扇区是磁盘物理操作的基本单位,而IO 块是磁盘操作的逻辑单位,一个IO块对应一个或多个扇区,扇区大小一般为512个字节。所以各个块大小的关系可以梳理如下:

DB block > OS block >= IO block > 磁盘 sector,而且他们之间保持了整数倍的关系。比如我的系统各个块的大小如下,DB以mysql为例,OS以linux为例。

DB block size

root@(none) 09:13:02>show variables like 'innodb_page_size';

+------------------+-------+

| Variable_name    | Value |

+------------------+-------+

| innodb_page_size | 16384 |

+------------------+-------+

OS block size

[1 Single:CHECK: mysql ~ ]

$ getconf PAGESIZE

4096

IO block size

比如查看sdb1分区的IO block size

[root@chuckkkk]# blockdev --getbsz /dev/sdb1

4096

sector size

[root@chuckkkk]# fdisk -l | grep Sector

Sector size (logical/physical): 512 bytes / 512 bytes

从上面的结果可以看到DB page=4*OS page=IO page=8*sector size。

由于任何DB page的写入,最终都会转为sector的写入,如果在写磁盘的过程中,出现异常重启,就可能会发生一个DB页只写了部分sector到磁盘,进而出现页断裂的情况。

页断裂与数据库一致性

前面我们分析了异常重启一定会导致页断裂,而页断裂就意味着数据库页面不完整,那么数据库页面不完整是否就意味着数据库不一致呢???我们知道,数据库异常重启时,自身有异常恢复机制,我这里不打算展开讲异常恢复机制,因为不同数据库的异常恢复流程不同。主流数据库基本原理类似:第一阶段重做redo日志,恢复数据页和undo页到异常crash时的状态;第二阶段,根据undo页的内容,回滚没有提交事务的修改。通过两个阶段保证了数据库的一致性。对于mysql而言,在第一阶段,若出现页断裂问题,则无法通过重做redo日志恢复,进而导致恢复中断,数据库不一致。这里大家可能会有疑问,数据库的redo不是记录了所有的变更,并且是物理的吗?理论上来说,无论页面是否断裂,从上一个检查点对应的redo位置开始,一直重做redo,页面自然能恢复到正常状态。对吗?讲清楚这个问题,先讲讲重做日志(redo)格式。

重做日志(redo)格式

数据库系统实现日志主要有三种格式,逻辑日志(logical logging),物理日志(physical logging),物理逻辑日志(physiological logging),而对于redo日志,则主要采用物理日志和物理逻辑日志两类。逻辑日志,记录一个个逻辑操作,不涉及物理存储位置信息,比如mysql的binlog;物理日志,则是记录一个个具体物理位置的操作,比如在2号表空间,1号文件,48页的233这个offset地方写入了8个字节的数据,通过(group_id,file_id,page_no,offset)4元组,就能唯一确定数据存储在磁盘的物理位置;物理逻辑日志是物理日志和逻辑日志的混合,如果一个数据库操作(DDL,DML,DCL)产生的日志跨越了多个页面,那么会产生多个物理页面的日志,但对于每个物理页面日志,里面记录则是逻辑信息。这里我举一个简单的INSERT操作来说明几种日志形式。

比如innodb表T(c1,c2, key key_c1(c1)),插入记录row1(1,’abc’)

逻辑日志:

<insert OP, T, 1,’abc’>

逻辑物理日志:

因为表T含有索引key_c1, 一次插入操作至少涉及两次B树操作,二次B树必然涉及至少两个物理页面,因此至少有两条日志

<insert OP, page_no_1, log_body>

<insert OP, page_no_2, log_body>

物理日志:

由于一次INSERT操作,物理上来说要修改页头信息(如,页内的记录数要加1),要修改相邻记录里的链表指针,要修改Slot属性等,因此对应逻辑物理日志的每一条日志,都会有N条物理日志产生。

< group_id,file_id,page_no,offset1, value1>

< group_id,file_id,page_no,offset2, value2>

……

< group_id,file_id,page_no,offsetN, valueN>

 

因此对于上述一个INSERT操作,会产生一条逻辑日志,二条逻辑物理日志,2*N条物理日志。从上面简单的分析可以看出,逻辑日志的日志量最小,而物理日志的日志量最大;物理日志是纯物理的;而逻辑物理日志则页间物理,页内逻辑,所谓physical-to-a-page, logical-within-a-page。

redo格式与数据一致性

回到“发生页断裂后,是否会影响数据库一致性”的问题,发生页断裂后,对于利用纯物理日志实现redo的数据库不受影响,因为每一条redo日志完全不依赖物理页的状态,并且是幂等的(执行一次与N次,结果是一样的)。另外要说明一点,redo日志的页大小一般设计为512个字节,因此redo日志页本身不会发生页断裂。而逻辑物理日志则不行,比如修改页头信息,页内记录数加1,slot信息修改等都依赖于页面处于一个一致状态,否则就无法正确重做redo。而mysql正是采用这种日志类型,所以发生页面断裂时,异常恢复就会出现问题,需要借助于double write技术来辅助处理。

double write处理页断裂

doublewrite是Innodb表空间内部分配的一片缓冲区,一般double write包含128个页,对于pagesize为16k的页,总共2MB,doublewrite页与数据页一样有物理存储空间,存在于共享表空间中。Innodb在写出缓冲区中的数据页时采用的是一次写多个页的方式,这样多个页就可以先顺序写入到doublewrite缓冲区,并调用fsync()保证这些数据被写出到磁盘,然后数据页才被写出到它们实际的存储位置并再次调用fsync()。故障恢复时Innodb检查doublewrite缓冲区与数据页原存储位置的内容,若doublewrite页处于页断裂状态,则简单的丢弃;若数据页不一致,则会从doublewrite页还原。由于doublewrite页落盘与数据页落盘在不同的时间点,不会出现doublewrite页和数据页同时发生断裂的情况,因此doublewrite技术可以解决页断裂问题,进而保证了重做日志能顺利进行,数据库能恢复到一致的状态。

oracle如何处理页断裂

oracle与mysql一样,采用的redo日志也是逻辑物理格式,但没有doublewrite技术。我一直就想着oracle这么牛逼的数据库,一定有它自己的方式来应对这种问题。也许这就是所谓的蛮目崇拜,找了N久资料,中文的英文的,包括咨询何登成大神,基本能得出一个结论oracle遇到页断裂问题,一样会挂,重启不来。但是oracle有一个相对简单的策略来恢复数据库到一致状态,备份+归档日志。备份保证了数据页不发生页断裂,加上归档日志增量可以恢复到某个时间点。为什么不做呢?我想一般使用oracle都会使用DataGuard做容灾,主库发生故障时,备库会承担起主库的责任,然后异常主库通过备份+归档日志的方式来恢复,虽然不如doublewrite技术快,但也是能恢复出来的。

其他方式解决页断裂

前面讨论的都是基于一个假设,异常重启后,一定会导致页断裂,其实在底层设施在一定程度上是可以解决这个问题的,比如文件系统层面,采用ZFS文件系统,ZFS通过日志的方式保证了OS页面的完整性,从底层防止了页断裂问题;在磁盘层面,一般RAID卡都会有带电缓存,即使OS异常重启,缓存数据也不会立即丢失,因而也能保证不发生partial write问题。但是我在想,OS的pagesize比DB的pagesize要小,即使能保证OS page不发生页断裂,也不能保证DB page 不断裂,个人感觉不能彻底解决。当然了,如果将DB pagesize设置成和OS pagesize一样大,就没问题了。

 

参考文档

http://blog.csdn.net/oneyearlater/article/details/7720723

http://www.percona.com/blog/2006/08/04/innodb-double-write/

http://blog.itpub.net/22664653/viewspace-1140915/?page=2

http://www.vmcd.org/2014/09/1748/

 

posted @ 2014-09-08 12:19  天士梦  阅读(5274)  评论(2编辑  收藏  举报