之前有网友希望我对mysql的double write和oracle能够做一个对比,其实这种对比方式挺好,能够触类旁通,举一反三。不过限于本人水平有限,欢迎拍砖。
关于MySQL的double write是对partilal write的一个补充。比如将数据写入磁盘的时候,发生了断电情况,那么一部分内容写入一部分就丢失了,这个时候使用redo log来恢复就不可行了,因为从日志文件层面数据的变更已经是不完整的了。
double write的大体是这样的。部分内容参考了链接 http://www.cnblogs.com/benshan/archive/2013/01/14/2859336.html
double write分为两部分,一部分是doublewrite buffer,大小为2M,另外一部分就是物理磁盘上的共享表空间中连续的128个页,即两个区,大小同样为2M。当缓冲池的胀业刷新时,并不直接写硬 盘,而是通过memcpy函数将脏页先拷贝到内存中的doublewrite buffer,之后通过doublewrite buffer再分两次写,每次写入1M到共享表空间的物理磁盘上,然后马上调用fsync函数,同步磁盘。
这个问题可以简单的归结为innodb恢复的原理,从这个层面来说和oracle还是存在着很大的不同。
首先double write是限于Innodb 存储引擎的,而且是作为一个可选的方案,通过参数InnoDB_doublewrite的值来控制,如果为0表示不启用,可以通过show status like "%InnoDB_dblwr%"来查看。
既然作为可选方案,肯定是有一定的原因,就是出于性能的考虑,位于共享表空间的double write buffer其实也是文件,写double write buffer本身也会有fsync操作,只是double write写入的过程是一个顺序写的过程,所以对性能降低不会太低。
oracle的恢复机制相比double wriite更加灵活和全面。
首先oracle中采用了undo+redo机制来作为数据恢复的基石,数据的恢复是通过前后台结合来实现的,在缓存级别,存在dbwr,能够把修改后的数据块刷入数据文件,这是一个异步的过程,不会因为发生数据变更就马上写入数据文件,同时存在log buffer,能够通过log buffer生成redo日志,最后通过lgwr把这部分变更刷到redo 日志,在这个过程中lgwr负责了保持数据完整性的任务,保证了数据在任何情况下都不会丢失。
上面的操作,写入数据文件的过程不是实时的,可以存在一定的延时,所以重点就放在了redo日志上面,在备份恢复方面还是最重要的。
如果在dbwr把数据变更的数据块写入数据文件的时候,如果发生断电的情况,当实例重新启动的时候,oracle会根据redo 日志构造出变更前的数据块信息,从而完成了前滚,把丢失的数据块找回来。这样数据库就恢复为了奔溃前的状态,如果某些事务没有提交或者回滚,又会继续做一个回滚操作。这个过程会通过smon来结合Undo来实现。
从整个过程来说,oracle支持的面很广,就如Oracle所承诺的那样,做了commit的数据就能够恢复。从IO消耗的角度来看,物理IO的消耗就在于刷新数据到数据文件,数据变更写入redo,没有额外的物理IO。
结合MySQL来看,double write buffer扮演的角色有点类似 log buffer的作用。因为oracle已经开辟了log buffer的缓存空间,所以缓存级的IO还是很快的,double write buffer就会存在部分的物理IO操作。
不过从技术的架构和角度来看,不能完全说出某一种好还是不好,从目前的分析来看,oracle相比double write还是技高一筹,不过从体系结构上要复杂的多。而且还涉及到更多的细节需要优化。
关于MySQL的double write是对partilal write的一个补充。比如将数据写入磁盘的时候,发生了断电情况,那么一部分内容写入一部分就丢失了,这个时候使用redo log来恢复就不可行了,因为从日志文件层面数据的变更已经是不完整的了。
double write的大体是这样的。部分内容参考了链接 http://www.cnblogs.com/benshan/archive/2013/01/14/2859336.html
double write分为两部分,一部分是doublewrite buffer,大小为2M,另外一部分就是物理磁盘上的共享表空间中连续的128个页,即两个区,大小同样为2M。当缓冲池的胀业刷新时,并不直接写硬 盘,而是通过memcpy函数将脏页先拷贝到内存中的doublewrite buffer,之后通过doublewrite buffer再分两次写,每次写入1M到共享表空间的物理磁盘上,然后马上调用fsync函数,同步磁盘。
这个问题可以简单的归结为innodb恢复的原理,从这个层面来说和oracle还是存在着很大的不同。
首先double write是限于Innodb 存储引擎的,而且是作为一个可选的方案,通过参数InnoDB_doublewrite的值来控制,如果为0表示不启用,可以通过show status like "%InnoDB_dblwr%"来查看。
既然作为可选方案,肯定是有一定的原因,就是出于性能的考虑,位于共享表空间的double write buffer其实也是文件,写double write buffer本身也会有fsync操作,只是double write写入的过程是一个顺序写的过程,所以对性能降低不会太低。
oracle的恢复机制相比double wriite更加灵活和全面。
首先oracle中采用了undo+redo机制来作为数据恢复的基石,数据的恢复是通过前后台结合来实现的,在缓存级别,存在dbwr,能够把修改后的数据块刷入数据文件,这是一个异步的过程,不会因为发生数据变更就马上写入数据文件,同时存在log buffer,能够通过log buffer生成redo日志,最后通过lgwr把这部分变更刷到redo 日志,在这个过程中lgwr负责了保持数据完整性的任务,保证了数据在任何情况下都不会丢失。
上面的操作,写入数据文件的过程不是实时的,可以存在一定的延时,所以重点就放在了redo日志上面,在备份恢复方面还是最重要的。
如果在dbwr把数据变更的数据块写入数据文件的时候,如果发生断电的情况,当实例重新启动的时候,oracle会根据redo 日志构造出变更前的数据块信息,从而完成了前滚,把丢失的数据块找回来。这样数据库就恢复为了奔溃前的状态,如果某些事务没有提交或者回滚,又会继续做一个回滚操作。这个过程会通过smon来结合Undo来实现。
从整个过程来说,oracle支持的面很广,就如Oracle所承诺的那样,做了commit的数据就能够恢复。从IO消耗的角度来看,物理IO的消耗就在于刷新数据到数据文件,数据变更写入redo,没有额外的物理IO。
结合MySQL来看,double write buffer扮演的角色有点类似 log buffer的作用。因为oracle已经开辟了log buffer的缓存空间,所以缓存级的IO还是很快的,double write buffer就会存在部分的物理IO操作。
不过从技术的架构和角度来看,不能完全说出某一种好还是不好,从目前的分析来看,oracle相比double write还是技高一筹,不过从体系结构上要复杂的多。而且还涉及到更多的细节需要优化。