MongoDB 升级

为啥要升级?

更好的性能,和更少的 bug。

2.6 相对于 2.4,得益于引擎的升级,存储时的锁从 db 降为 collection;

3.0 相对于 2.6,如果用了 wiredtiger,存储时的锁可以从 collection 降为 document!

实际试下来发现,性能有极大的优化,锁住的比例降低很多,吞吐率和时间表现都好很多;而且,如果使用 wiredtiger,会发现磁盘占用量少很多(至少节省 1/2)。对升级的结果非常满意。

如何升级?

首先,不能跳跃升级,也就是 2.4 无法直接升级到 3.0,必须 2.4 => 2.6,2.6 => 3.0。稍稍有些麻烦。

基本过程比较简单,都是停止 mongod 进程,用新的 mongod 程序使用原来的配置文件和原来的存储空间启动。

对没有使用 replica 的 mongod,升级过程会导致无法服务,不过,生产环境用 standalone 的情况,很少吧。

对 replica,要一台一台升级,集群内的 mongod 可以是不同的版本,升级过程不会中断服务。为了防止停止一台 mongod 时,无法 vote 出来 primary,停止前要检查一下集群内可用 mongod 数量,必要时需要添加 arbiter 用作投票,整个集群升级完毕后再干掉它。

对 shard,集群内的 replica 按照上面的方式升级;mongos 升级很简单,用新的 mongos 启动即可,但是要注意重启的过程防治有请求打到挂掉的 mongos 上。config 升级前,要停掉 balancer,然后逐个升级。整个升级过程也不会中断服务。

升级后,用户监控或备份的 mms,也要升级,否则可能无法正常工作。 此外,开发语言使用的驱动,也需要做相应升级,否则可能无法正常使用。

切换存储引擎到 wiredtiger,这个非常推荐,一个是能极大减少磁盘占用量,存储锁机制的修改,对性能的提升有极大的好处。stand alone 的机器就别升级了。replica 的机器,需要逐个升级,需要用新的地方数据库存储文件或干掉原来的存储文件,如果使用了旧版的 config 格式,也需要升级到新版,启动 mongod 等待数据传输号即可。

最后,2.4 升级到 3.0,小心操作的话,实际过程很顺利,带来的性能提升非常明显,很棒!

标签: none

添加新评论