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

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

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