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

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

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

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

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

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

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