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

  • 崔康

2012 年 3 月 28 日

话题:数据库测试持续集成语言 & 开发架构文化 & 方法

乔梁 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 

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

数据库测试持续集成语言 & 开发架构文化 & 方法