MySQL里的double write是InnoDB的三大闪亮特性，另外两个是insert buffer 和自适应哈希，其实还有几个比如异步IO，Flush neighbour Page(刷新邻接页），这个和系统层面的关联性较高，所以三大亮点还是更有针对性的。 当然一说到MySQL里的double write,其实主要是要应对一个很自然的问题，那就是partial write。 这个问题比较经典，很多数据库设计中都需要考虑到这样一个临界点的问题，MySQL中的页是16k,数据的校验是按照这个为单位进行的，而操作系统层面的数据单位肯定达不到16k,比如是4k,那么一旦发生断电的时候，只保留了部分写入，如果是Oracle DBA一般对此都会很淡定，说用redo来恢复嘛，但是可能我们被屏蔽了一些细节，MySQL在恢复的过程中一个基准是检查page的checksum，也就是page的最后事务号，发生这种partial page write 的问题时，因为page已经损坏，所以就无法定位到page中的事务号，所以这个时候redo就无法直接恢复。 由此引申一点，partial write的问题在Oracle中肯定也会存在，但是只是Oracle替我们把这个过程平滑的做好了。其中有设计的差异，还有恢复技术的差别。但是无论如何这个问题都不会绕过去，还得解决。 所以这一类问题，如果讨论起来，那可以讨论很长时间，可以把体系结构里的方方面面拿出来分析，做对比。 对此我画了一个相对简陋的图，也欢迎大家提出改进建议。 总体来说，double write buffer就是一种缓冲缓存技术，主要的设计就是为了防止数据在断电，异常情况下丢失数据。里面有几个点需要注意的就是，数据在buffer pool中修改后成了脏页，这个过程会产生binglog记录和redo记录，当然数据写入数据文件是一个异步的工作，如果细看，在共享表空间（system tablespace）中会存在一个2M的空间，分为2个单元，一共128个页，其中120个用于批量刷脏数据，另外8个用于Single Page Flush。根据阿里同学的分析主要是做区分是因为批量刷脏是后台线程做的，这样不影响前台线程。而Single page flush是用户线程发起的，需要尽快的刷脏并替换出一个空闲页出来。所以不是一个严格的64 64的拆分。 而数据刷新的过程，是先使用memcopy把脏数据复制到内存中的double write buffer,分两次写完，每次写1MB到共享表空间，然后就是调用fsync来同步到磁盘。这里有一点需要注意的是，这个刷新到共享表空间的过程，虽然是两次，但是是顺序写，所以开销不会很大，也就不会像大家想象的double write性能可能很差，根据Percona的测试，大概也就是5%左右的差别，数据重要还是性能更重要，这是一个基本的命题。当然后续会再写入对应的表空间文件中，这个过程就是随机写，性能开销就会大一些。所以在早些时候是用SSD的时候很多人也会带有如此的顾虑，顺序写还是随机写。 当然double write这么设计就是全面为了作为恢复而用，要不这么大张旗鼓就不值得了。这个图来源于 http://blog.csdn.net/renfengjun/article/details/41541809 我觉得已经说得很明白了，就直接引用过来了。 可以看到里面的一个中心词就是checksum,如果出现了partil write的时候，比如断电，那么两次写的过程中，很可能page是不一致的，这样checksum校验就很可能出现问题，而出现问题的时候，因为有了前期写入共享表空间的页信息，所以就可以重构出页的信息重新写入。 double write其实还有一个特点，就是将数据从double write buffer写到真正的segment中的时候, 系统会自动合并连接空间刷新的方式, 这样一来每次就可以刷新多个pages，提高效率。 比如下面的环境，我们可以根据show status的结果来得到一个基本的合并页的情况。 |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
