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

MySQL里的double write是InnoDB的三大闪亮特性,另外两个是insert buffer 和自适应哈希,其实还有几个比如异步IO,Flush neighbour Page(刷新邻接页),这个和系统层面的关联性较高,所以三大亮点还是更有针对性的。

当然一说到MySQL里的double write,其实主要是要应对一个很自然的问题,那就是partial 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问题

对此我画了一个相对简陋的图,也欢迎大家提出改进建议。

总体来说,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其实还有一个特点,就是将数据从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 就可以得到,通过指标也可基本看明白。

Percona中的double write改进

当然对于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/

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2017-03-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Golang语言社区

棋牌游戏服务器架构: 总体设计

首先要说明的是, 这个棋牌游戏的服务器架构参考了网狐棋牌的架构。网狐棋牌最令人印象深刻的是其稳定性和高网络负载。它的一份压力测试报告上指出:一台双核r的INTE...

7526
来自专栏Java技术栈

通往Java 9之路:每年两次发布即将到来

Oracle将加速标准Java的发布,每六个月推出一个新版本的Java开发工具包(JDK),每三年更新一次长期支持的版本。因此,下个版本的Java9将在2018...

3355
来自专栏小怪聊职场

架构|如何架构一个合适的企业API网关(1)API网关的介绍、应用场景、作用及常用方案

5148
来自专栏IT技术精选文摘

10个最重大的Web应用风险与攻防

先来看几个出现安全问题的例子 ? ? ? ? ? OWASP TOP10 ? 开发为什么要知道OWASP TOP10 ? TOP1-注入 ? TOP1-注入的示...

2839
来自专栏移动开发试验田

【移动开发】市面上主流「移动推送服务」的体验比较

推送服务基本上是每个 App 的刚需,自己也用过许多家推送服务,最近腾讯云上线了一个类似于 firebase 的移动开发平台,上面集成了很多的移动服务,包括推送...

4117
来自专栏IT笔记

微服务化的基石——持续集成

在很多微服务化的文章中,很少会把持续集成放在第一篇,因为大多数的文章都会将如何拆的问题,例如拆的粒度,拆的时机,拆的方式。

5839
来自专栏杨建荣的学习笔记

明天,实现几个还不错的功能点

明天,计划实现几个还不错的功能,算是个自己这段时间的运维里程碑划上一个句号。里程碑是自己制定的,目的是督促自己做事情有一个预期目标,在糟糕的实现中不断迭...

1162
来自专栏java思维导图

大型分布式网站架构技术总结

#0 系列目录# 大型分布式网站架构 大型分布式网站架构技术总结 本文是学习大型分布式网站架构的技术总结。对架构一个高性能,高可用,可伸缩,可扩展的分布式网站进...

3914
来自专栏架构说

分布式配置中心架构与实战

声明:信息来源 docker.io 分享主题:分布式配置中心架构与实战 分享主题:分布式配置中心架构与实战 声明 信息来源docker.io 今天的大规模...

1.2K8
来自专栏技术小黑屋

Google Play Services 7.5新增API及多项特性

本文为 InfoQ 中文站特供稿件,首发地址为:文章链接。如需转载,请与 InfoQ 中文站联系。

1352

扫码关注云+社区

领取腾讯云代金券