MongoDB升级小结

背景

最近业务mongo升级，因为需要调整业务代码和线下测试，工作持续了一个月才有了阶段性的成果。

• 版本升级一定要在测试环境成功测试后再在production机器上进行版本升级。业务代码主要是Python，在升级之前，我们已更新到了合适版本的pymongo，并在线下做了测试。
• 为了从2.4升级到3.0由于数据兼容性的问题，需要先从2.4升级到2.6，然后再从2.6升级到3.0。
• mongo没有用yum安装，直接拷贝的mongo的bin文件，在机器上运行mongd启动。下载地址
• mongo没有采用分片。

mongo2.4到2.6

这次升级在很久之前由开发人员自己完成。

升级的过程

1. 升级从库
   主要操作：将2.4版本mongo的二进制文件替换成2.6的程序包里的bin目录里的二进制文件，然后重启。待mongo从recoer状态变为secondary状态后， 再升级下一个mongo 实例。可以在mongo shell中用rs.status()查看实例状态。

2. 停掉主库

3. 升级主库

升级的好处

1. 建索引是一个容易引起长时间写锁的问题，MongoDB 在前台建索引时需要占用一个写锁（而且不会临时放弃），如果集合的数据量很大，建索引通常要花比较长时间，特别容易引起问题。MongoDB 提供了两种建索引的访问，一种是 background 方式，不需要长时间占用写锁，另一种是非 background 方式，需要长时间占用锁。使用 background 方式就可以解决问题。
   但mongo2.4在建索引的时候，即使指定了background；在从库重放时，依然会阻塞数据库的访问。这个问题在2.6中得到修复，这样在运行中mongo集群中新建索引，不用担心阻塞。对于我们这种小步快跑的业务，真是解决了一大痛点。

mongo2.6到3.0

这次升级由DBA操作，业务侧配合。此次升级，直接切换了新的数据库引擎。

升级的过程

1. 升级离线从库
   2.6升级到3.0前需要验证现有的用户schema, 在3.0中MongoDB完全弃用了之前的用户授权验证模式，所以在升级3.0前需要把2.6的用户schema升级到兼容3.0的格式。
   停掉mongod，将2.6版本mongo的二进制文件替换成下载的3.0程序包里的bin目录里的二进制文件，然后重新启动mongod。

2. 升级在线从库
   主要就是拷贝数据，重启一个mongo3.0的实例。

3. 升级主库
   因为升级期间，在mongo选主时有短时间的只读。为了防止数据写失败，在升级前，我们重发了业务代码，所有写mongo操作的接口进入维护状态。
   DBA操作：停掉旧的主库，mongo集群会重新选主；然后直接把从库的文件拷贝到原主库机器，启动一个mongo3.0的实例；然后把实例加入到replica中，最后重新将主库归位。

升级的好处

1. 因为切换了存储引擎，升级后节省了大量磁盘空间，这是最直观的收益。
2. 在此之前，我们业务的mongo一直是自己运维。DBA更是嫌弃我们这边的mongo版本太老，不愿意接管。这次升级之后，基本可以交付给DBA托管，少操心很多了。

小结

1. 术业有专攻，数据库运维还是交给DBA来做较好。
2. 升3.0后，mongo机器的cpu负载会比升级之前高，在升级之前应加以评估，贸然升级把cpu打满可能出现意外。
3. mongodb的副本集至少需要3台以上才能实现高可用，并且节点的个数最好是基数。我们实际采用的1主2在线从库2离线从库。
4. 为了把对业务的影响降到最低，数据库升级一般放在访问低估进行。我们此次升级是在凌晨3点进行的，熬夜伤身呐。