BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

2012.3.28微博热报:持续集成中的自动化测试、InnoDB写处理

| 作者 崔康 关注 1 他的粉丝 发布于 2012年3月29日. 估计阅读时间: 8 分钟 | AICon 关注机器学习、计算机视觉、NLP、自动驾驶等20+AI热点技术和最新落地成功案例。

微博上,大家针对持续集成中自动化测试的定位以及InnoDB中Doublewrite写处理的细节展开了热烈的讨论。

乔梁QL在微博上针对持续集成的自动化测试发表了自己的看法:在做#持续集成#实践时,如果把自动化测试看做是“找bug”的,那么你就错了。如果把自动化测试看做是“测试人员用的”,那么你也做错了。

大家随后表达了自己的意见:

横刀天笑: 在公司跟他们说自动化测试的时候,大家问的最多的问题是用了自动化测试可以帮助QA找到多少bug,能覆盖多少情况。我觉得自动化测试是一个能快速反馈的安全网,一颗能建立信心的定心丸。

行人23: 自动化测试:让发布人员对快速上线更有信息,尤其是保证修改bug时没有改出严重的bug;对开发人员来说,将更多的bug暴露在开发期,大幅降低与测试之间的沟通周期;对测试人员来说,一边喝咖啡一边看测试结果。

加周V博: 持续集成和自动化测试让质量真正做到了全员参与,而希望帮QA找BUG的人们还是把质量看做QA一个人的事。

周峰_:对观点表示赞同,自动化测试用例更多的由开发人员写,测试人员的贡献更多在于决定ta要测什么,另外就是对需求的把握,以及探索性测试。

Please严肃点儿:这实际是对快速反应出小版本的一个技术补充,没有自动测试,实际快速迭代就是空中楼阁。而且,我原来公司developer这端都需要有自动测试,关注点和力度不同罢了,但是很需要也很有帮助。 

何_登成在微博上提了几个有关InnoDB写处理的问题:InnoDB有Doublewrite,其目的是为了写dirty page时不至于出现half written (partial page write)问题,个人有几个疑问:1. 什么情况下会出现此问题?2. 出现half written的概率有多大?3. 什么情况下可以杜绝此问题?4. 其他数据库如何处理此问题?

大家对此展开了讨论:

plinux:有的文件系统不支持写事务,可能一个Page写到一般宕机了,但是这一般被持久化了,像ZFS自带文件系统写入原子性保证,就不用Doublewrite

何_登成:回复@plinux: 据我所知,ZFS用的是copy-on-write技术吧,写在不同的地方,只改元数据指针即可,这样倒是可以避免half written。除了ZFS,其他的文件系统,或者说是硬件设备能够避免half written问题吗?例如带电池的RAID?还有,真正发生half written的概率有多大?

plinux:回复@何_登成:我只知道ZFS和BtrFS支持COW能保证写入原子性。其他文件系统如果能做到一个page大小的sector size也就是写入单位,也能保证原子吧,像XFS可以格式化为4K的 sector size,我用InnoDB 4K的页,应该可以保证?这个需要霸爷专业指导了,IO是个无比复杂的系统。

何_登成http://t.cn/zOX7BTR 测试,DoubleWrite对性能的影响不到3%,IO吞吐量增加一倍左右;http://t.cn/zOXZIBu中,Mark Callaghan不喜欢DoubleWrite方案,据其描述与后面的讨论,Oracle等不需要DoubleWrite的原因是其能够从一个partial write page中恢复出正确的page,而InnoDB不能,因此使用DoubleWrite

sleebin9:默认情况下InnoDB的page是16K,系统不能保证其被完整的写入磁盘。可能出现这样的情况,1.LSN被写入了磁盘,但是数据没有写入。2.数据写入了,但是slot的内容没有更新。InnoDB 在一个页上修改一条记录时,会修改好几个地方。

hellodba:我觉得Oracle也不能避免这个问题,很多时候Oracle掉电后发现坏块无法启动,就是因为这个原因。那为什么MySQL才有doublewrite,而Oracle没有呢?有个观点是“在某些情况下,Oracle可以用redo去恢复HalfWritten的块,可以减少发生问题的概率“,但这种说法并不肯定,还有待证实。

阿里八神:根据解析redo日志的牛人解释,oracle的恢复分为很多种,对于instance recover,oracle是可以认为这种坏块可以强行用redo去覆盖应用的,对于介质恢复,每个block需要严格的checksum检查,如果出现坏块,就挂了。底层存储掉电,这个是完全脱离了数据库保障体系的,换了任何数据库,都搞不定。

何_登成:回复@阿里八神:DoubleWrite就是为了解决这个问题的。所有的脏页都写两份,一份写成功之后,再写到原有位置。如果原有位置写坏,则说明对应的一份一定写成功了,复制过来就行。带来的代价则是,IO吞吐量加倍。

eygle:看了一下InnoDB,其日志格式也是PhysioLogical模式,与Oracle的日志原理一致,但是记录的信息更少,而其DoubleWrite实际是表空间上预留的连续空间(100 pages),其理念与日志一致,还是期望连续写降低随机写的性能影响。从发生概率上,InnoDB缺省16K的块,比通常Oracle 8k的块,不一致的概率肯定更高。Oracle的日志在其技术路线上,可以实现更复杂的功能,包括DG、GG、复杂的恢复等,我估计InnoDB的日志恢复要弱些。Oracle数据库对于写出校验是非常多种多样的,比如在数据库启动时,会有一个判断是,去检查最后一个成功写出的数据块状态,如果该块状态不正常,则判定肯定会存在数据写丢失。通常Oracle出现Partial page write的概率很低,但是在存储故障时,存储丢失写操作,数据库没有任何办法保证一致性,在此情况下可能出现大量的Partial page write,此时除了介质恢复,没有其他好办法,这种情况我们遇到的较多。

淘宝褚霸:所以为低概率事件把软件搞的极其复杂不是太划算的事情。 数据库只要说明白了要什么硬件支持,通常应该会得到满足的,这样就可以简化很多软件上的各种挖空心思的为灾难避免做的努力。

caole82:double write只是保证页面完整性的一种办法。某些商业数据库在page的头尾都有校验,一个写入完整的page,页头和页尾的校验位是相同的。一旦两者不同,则从最近的image copy读取该page,重打redo log就可以恢复该page 

今日微博推荐

乔梁QL

推荐理由:拥有丰富的软件开发及项目管理经验,专注于提高软件企业提高交付能力,推广最佳实践。现任百度项目管理部高级架构师,负责百度敏捷过程改进与持续交付推广实施。译有《持续交付》。

欢迎读者关注@InfoQ官方微博,推荐热门话题,可私信@InfoQ,同时请您说明推荐理由。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT