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

微博上，大家针对持续集成中自动化测试的定位以及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，同时请您说明推荐理由。