云服务商Mongodb内核版本升级的初步想法

                云服务商Mongodb内核版本升级的初步想法

前言:   

Mongodb 3.6.0正式版本 于2017年12月  1日发布

    Mongodb 3.4.0 正式版本 于2016年11月26日发布

    Mongodb 3.2.0 正式版本 于2015年12月  4日发布 

从上面可以看出Mongodb保持一年一个大版本，而每个大版本下面的小版本基本上就是一个月一个迭代版本用于解决各个bug. Mongodb公司2017年10月在纳斯达克上市，作为上市公司相对其他的开源数据库有更多的金钱和人力去发展Mongodb,估计后面Mongodb版本迭代的速度会更快，那作为Mongodb云服务商我们怎样去适应这种版本的快速迭代呢？我们先分析面对的问题，然后再提出相应的解决方案，当然方案不完美，只是一些初步的想法。

云服务商Mongodb已上线版本面对的问题:

1. 社区小版本重大bug的修复

对于社区某个版本的重大bug，Mongodb官方的建议一般是升级你的Mongodb到此大版本下的最新版本。由于都是相同的大版本不会存在版本兼容性问题，只需要按顺序替换不同节点的Mongodb二进制源码就行，看起来so easy。但存在可能这个升级版本解决了一个重大bug但他本身却引入或含有没有修复的其他重大bug,那到时是不是又要升级更新版本？

2. 大版本之间的升级

当用户想使用新的大版本中某个新特性或者一些大版本由于过于久远不再维护，就需要进行大版本升级，而大版本升级最大的问题在于非兼容特性的升级，以及升级失败后进行降级的处理(大版本升级步骤可见文档最后)

3.社区快速发布的大版本:

快速增长的版本列表:

由于社区大版本发布速度越来越快，云服务商如果跟踪社区大版本，那云服务商Mongodb的版本也会越来越多，用户在选择版本的时候也会疑惑，到底选择哪个？维护版本需要的人手也会也来越多，有些版本可能只有极少用户用但也需要人力进行维护

问题总结就是：面对快速迭代的社区版本，云服务商采用什么样的策略，在给定的人力下提供给用户相对社区版更安全更满足用户需求的云服务Mongodb.

云服务商Mongodb内核版本迭代方案

1. 确定社区大版本选择的标准

各个大版本新增的特性在官网都有详细的说明，有些大版本相对前版本可能增加了一些新的操作，完善了客户端的可靠机制，这些虽然能提高用户使用的易用性，但在特性或性能或安全性上没有质的飞越，例如3.6版本更多的是更新了客户端的seesion机制提供因果一致性以及一些新的操作，这些新特性可能客户使用的比较少。而在2018年夏天即将推出的4.0，一个最大的特性是支持多文档事务机制，提供ACID，这个特性将颠覆Mongodb的弱一致性，可以看出Mongodb向金融业务这种对数据一致性要求极其严格领域提供服务的决心，这种大有质的飞越的特性云服务商Mongodb就需要跟踪和支持。当然所谓质的飞越的特性见仁见智，需要各自确定选择标准。

2. 大版本下小版本的选择

社区版本再发布一个大版本之后一段时间的的小版本都会存在很多的bug,有的bug会影响数据的可靠性。要达到能在现网环境使用最好要等待6个月以上，等待社区推出7-8个小版本。

3. 云服务商Mongodb小版本的快速升级

小版本出现严重bug升级最新的小版本，这种升级要解决的问题主要是快速移植以前版本修改的地方并进行测试，而测试需要修改Mongodb本身的测试工具用以适配内核的修改，如果有积累后面会快很多。

4. 云服务商Mongodb大版本的快速升级

对于两个连续的版本或者可以跨版本升级的可以进行升级，这个和前面的小版本升级没多大的区别。但面对的是严格要求前版本的版本号的呢？例如升级3.6版本，必须要求前一个版本是3.4，可能只能走mongoexport和mongoimport这类数据迁移工具进行跨版本的升级。升级到新的版本后如果出现问题怎么进行降级呢？降级后的版本里面含有新版本的特性怎么处理呢？这又是一块大问题，后续再写相关的文章来讨论下。

注释：

3.4版本副本集升级流程:

1. 当前运行的版本至少是3.2版本，如果不是请升级到3.2

2. 3.4在一些特性上有兼容性的改变，在升级3.4之前，检查你的应用程序是否有使用这些特性

3. 一旦升级到3.4版本，对于3.2.7以及之前的版本是无法再回退回去的

4. 首先停掉副本集中的secondary,然后将mongod二进制替换成3.4,重启secondary等待secondary状态正常。

5. 连接到primary上执行rs.stepDown()，强制降级选主。当选出新的primary的时候，停掉旧primary并替换mongod二进制为3.4.然后重启

6. 到这一步的时候，就可以使用3.4版本(除了3.4不兼容3.2的特性)，强烈建议运行一段时间（不带3.4非兼容特性）,以确保不会发生降级版本的情况

7. 在admin数据库上执行

db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } )，升级3.4完成。