前几天，公司一个业务部门的 Mongodb 数据库副本集（1主2从）出现写入和更新延迟现象，最慢的一次更新长达22秒，平均的更新和插入操作在15秒左右，上报到我们公共部门，希望能够得到解决。
之前业务部门已经对这个 Mongodb 使用了一个多月，一直没出问题，又怎么会突然发生延迟这么长的故障呢？
由于 Mongodb 中本写入的是重要的价格政策信息，所以这个故障已经影响正常线上业务了，于是我就担任救火队员，负责解决这个问题了。
于是灾难开始了： 1、删除索引 我们在出问题的集合中发现了一个3个字段的组合索引，而这个组合索引并没有被查询使用到，为了加速插入，我们决定在主库删除这个不使用的索引，然后让它同步到从库上，因为删除索引通常很快。 删除很快，5分钟左右，就把几千万条记录的集合的索引删除了，在我们删除完索引之后，主库的写入速度有了一定下降。没有之前那么夸张的平均15秒了，下降到了4-5秒。
2、恢复索引 这时Mongodb的集群出现报警，从库的读取性能急剧下降，外网业务频繁出现 504（time out）的错误。这时候我们其中的一个DBA同事以为我误删了那个索引引起的全表扫描，导致查询超时，于是他在主库上又将我刚才删除的索引重建了。 这时候更大的灾难降临了，在主库重建索引的时候，所有的主库写操作阻塞了，当主库创建完索引，将oplog同步到从库，从库创建完索引之后，两台从库在集群里的状态分别是：recovering和unreachable。 这时候整个Mongodb集群无法正常提供数据服务了，业务部门职能临时切换备用 sql 方案，勉强恢复对外提供服务，整个故障历时2小时。
3、事故分析： A、删除无用索引肯定会加快写入，但是为什么我删除了这个没有查询命中的索引，会让从库读取性能下降呢？ 主库删除索引，同步到从库之后，从库开始删除索引，这时候从库是无法从主库那边拉取同步数据的，因为删除索引会有一个写锁，所以当从库删除完索引之后，主库有大量的更新开始同步到从库，这时候从库压力倍增，导致读取性能下降。
B、恢复索引为什么会导致集群挂掉 DBA同事发现从库查询慢，以为是误删索引，其实并不是，而是由于之前从库删除索引停止同步引起的。 因为创建索引，会直接导致从库写入和读取的锁，并且耗时相比删除索引要长很久，所以两台从库就直接不提供服务了。 当从库创建完索引之后，从库和主库的数据不同步延迟相当大，大量的更新和外网的读取压力，导致整个Mongodb集群无法提供服务了。
4、解决问题 由于目前业务数据骤增，所以我们需要重新审视 Mongodb副本集 是否还能继续为我们提供服务，在Mongodb无法对外提供的时候，我们只能依靠多台redis和sqlserver数据库临时上线，应付业务。
A、在出故障的时候我们查看了Mongodb的状态，竟然有超过5000个连接，连接在主库上等待写操作。于是我们翻看了业务代码，发现10台服务器每台服务器的最大连接池设置了20000个，由于之前我们有测试Mongodb在大连接数下表现确实不佳，于是把代码改回默认的100个，继续跑数据，但是问题依旧，性能大约仍然在update操作 2000次/秒 左右。
B、因为业务的特殊性，集合中存储的当天之后的65天的价格政策信息，而之前没有定期清理垃圾数据，于是我们将过期的政策清理掉，大约清理掉了30%的数据，以为能够恢复原来的写入性能，无奈业务增长太快，就算清除了30%的垃圾数据，还是远远的超过以前的数据量，这个方式宣告失败。
C、翻阅网上Mongodb的资料，发现官方文档上有一些对于写操作的优化方案，文中提到使用SSD可以显著提升写操作的性能，最高可达20倍，于是折腾了运维，火急火燎的将3台Mongodb数据库机器全部加上SSD硬盘，由于换硬盘数据库要清楚，所以在换完硬盘前几小时写入性能非常高，但是当数据量上来之后，性能又跌回 2000次/秒，我们的数据量大约110G，内存当时配置了196G，所以SSD无法优化到写入操作。
D、再次翻阅Mongodb官方资料，发现Mongodb的文档是基于 usePowerOf2Sizes 这个规则来申请内存和空间的，当文档初始化插入4KB时，Mongodb申请的空间大小为8KB，当文档涨到8KB后，则申请16KB，以此类推。文档的增涨会带来数据块的迁移，带来性能损失，如果是文档初始化很小，会逐渐增涨，并增涨到一个相对初始大小很多倍的场景，那么官方推荐调整 usePowerOf2Sizes 这个设置，来初始化给文档分配一定的空间。我们的业务场景和这个很像，初始化只有1KB，以后的多次更新，最多可以将文档更新到80K。于是我们将文档初始化占用的空间设置为96KB，防止因为不断的数据块迁移带来的性能损耗，可惜这个配置还是然并卵。
E、无奈开始找其他出路，想到使用HBASE分布式kv存储方案来解决这个问题，了解到社区的@alsotang 正好非常熟悉HBASE这块，当天晚上就找 @alsotang 讨论解决方案，发现HBASE的查询条件太死，无法像Mongodb那样满足业务场景，经过这几天折腾，我得出结论就是因为并发写锁导致的性能低下，于是 @alsotang 给了我另外一个建议，批量写入，积攒大约几千条写的命令，批量插入。第二天的批量测试结果却是让人眼前一亮，性能从原来的2000次/秒 提升到了5000次/秒了，但是这样可能暂时能扛下来压力，过几个月业务增长之后，可能又存在瓶颈了。
F、由于我们线上使用的是Mongodb2.6，所以存在写入的库级锁，会不会是因为这个导致的并发写入性能低下呢？抱着吃螃蟹的心态，将数据库升级到3.0，还是之前批量写入的代码，空库的写入性能能达到 40000次/秒，在单表6000万数据量下，批量写入也能达到 18000次/秒，而且3.0的内存占用比2.6要少很多。 但是由于改成批量写入，业务端代码改动比较大，所以我们测试了非批量写入的情况，写操作性能也能达到8000次/秒。
G、最终我们还是决定一步到位，搭建了Mongodb3.0的集群，分6片存储之前单机Mongodb的数据，这样理论上能让我们的写性能翻5-6倍，就算不用批量写入，仍然可以达到40000次/秒，应该近几年业务是达不到这个指标的，而且一旦发现瓶颈，我们可以通过增加分片的方式提高集群性能。终于折腾了多天的Mongodb算是告一段落了，至于上线之后Mongodb3.0的坑是否会踩到，只能看脸了。
事故就分析到这里，期间研究了一些Mongodb的优化方案，传送门： http://snoopyxdy.blog.163.com/blog/static/6011744020157511536993/
用上了 3.0 啊，赞。是用的 WiredTiger 引擎吗？到时候等 WiredTiger 成为默认引擎的时候，我社区这边就升上去。听说后者性能比前者好很多，现在我们社区这边没有遇到性能瓶颈，所以暂时不动这里，还是用的 2.6。 hbase 这块，其实我也不是太熟悉，只是之前有项目用到了。我们是当做一个非内存的 kv 数据库在用，因为比较廉价嘛，支持的数据量大，自带数据分区支持，而且我们查询实时性要求不苛刻。但是如果有自有项目的话，除非搞大数据分析（已经超出我能力范畴）类的应用，否则我可能都不愿意去接触 hbase。它的使用场景太局限了，稍微一复杂就没法满足。
@alsotang 没办法啊，被逼着用3.0，是用的 WiredTiger 引擎，对数据是文档锁，不像以前是库锁的，所以插入和更新性能比之前好很多，很适用于写操作比较频繁的场景。hbase 最后还是没用上，下次有机会再用吧，确实感觉适用场景比较局限，先跑阵子看看吧，我们用的Mongodb 3.0.5，目前为止一切正常，不知道会不会踩到什么坑。。祈祷吧，哈哈~
@DoubleSpout cnode这边我用上3.0了。在国内机房这边，调试成功。wiredtiger对于数据的压缩，让数据总量从 200MB 变成了 60MB。不过话说，mongodb 以前的引擎被人诟病确实很多，现在上了 wiredtiger 感觉放心多了。不过应该还有很多次升级才会慢慢稳定的，但至少我这边是单机使用，碰坑的几率相对少一点。
@alsotang 现在cnodejs.org也用上3.0了吗？我感觉比原来好不少，空间占用小了，写入性能提高了，适当的降低下读取性能也能接受，锁的情况明细改善了，感觉Mongodb越来越来成熟了，单机你没做副本集？数据丢了怎么办呢？
虽然很多字，但是还是看完了。总体下来的感觉是： 1、对mongodb关注度不高 2、以关系型数据库的思维部署mongodb 个人经历：使用mongodb存储通信系统的消息等数据，对于2.6版本来讲库级别锁真的是谁用谁知道，当时的解决方案是起多端口做到一个库一张表（当然有些夸张，尽量保证一个库不会超过3张表，就是为了尽可能减少库级锁的影响），终于在众人的期待中mongodb发布了3.0版本，锁粒度到collection，引擎使用WT后性能提升很大一截，存储的话与2.6相比磁盘占用量也减少了一些，对于内存的开销从2.6的有多少吃多少到3.0的可以设定。一系列的调优让人眼前一亮；终于在3.0.2版本后按耐不住，将线上项目升级到3.X。对于部署来讲即使在2.6版本的mongodb，官方也是不建议使用主从部署的，在3.0更是标注将在下个大版本取消掉这种部署模式，mongodb的核心点在于部署，分片则是部署的核心点，而片键的选择更是分片的核心。当然，很难推动分片部署的原因在于主从<复制集<分片（数据冗余度，白话就是磁盘空间大小）。 最后，建议使用mongodb做线上项目存储的人，基本的了解下mongodb的概要（《mongodb权威指南》），有时候类比的思想并不一定试用所有地方。
@alsotang 主从一般会一主一从，或一主二从，而复制集部署最少是一个活跃节点和两个备份节点（原因在于如果活跃节点挂掉后，剩余的非活跃节点不仅要做数据备份，还要提供查询服务会挂的更快）。所以一般情况下复制集一份数据都要存储三份或更多。 关系型数据库的思维是指部署方案主从的选择以及不考虑死锁因素。对于主从方案，一般情况下为了容灾或是单点故障都会做数据的备份，很自然的会使用主从的模式，但是这种模式其实很需要外界的介入（比如主挂掉了自动漂移肯定是外部逻辑实现，不会像复制集一样自主选举），这样就是舍近求远的思路。对于死锁关注度不够，使用关系型数据库（比如mysql很自然的会将一些表存在同一个库下）习惯将多个表放在同一库中，这样一个表的逻辑出现锁将会影响本库（指2.6版本）所有表的业务逻辑。
