MySQL中的double write（二）(r12笔记第17天)

    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的结果来得到一个基本的合并页的情况。

> show status like '%dbl%';  
+----------------------------+----------+
| Variable_name              | Value    |
+----------------------------+----------+
| Innodb_dblwr_pages_written | 23196544 |
| Innodb_dblwr_writes        | 4639373  |
+----------------------------+----------+通过InnoDB_dblwr_pages_written/InnoDB_dblwr_writes  就可以得到，通过指标也可基本看明白。
   

   当然对于double write，在Percona中也在持续改进，在Percona 5.7版本中做了一个改进，你可以看到一个新的参数，innodb_parallel_doublewrite_path

| innodb_parallel_doublewrite_path | xb_doublewrite |在系统层面，也会存在一个30的一个文件对应。

-rw-r----- 1 mysql mysql 31457280 Mar 28 17:54 xb_doublewrite也就是并行double write,关于这个特性的详细描述和测试，可以参考。https://www.percona.com/blog/2016/05/09/percona-server-5-7-parallel-doublewrite/?utm_source=tuicool&utm_medium=referral

里面提供了很多详细测试的对比和分析。当然MariaDB,Facebook,Aurora也有一些自己的实现方式和考虑，这个限于精力，还没有细细测试分析。感兴趣的同学可以看一看。

参考链接：

https://yq.aliyun.com/articles/50627

http://blog.itpub.net/22664653/viewspace-1140915/