环境：

4个分片，各个分片3个节点。6台服务器，每台服务器都有2-3个 MONGOD （或 mongos) 进程 计划把硬盘，内存及MongoDB 从3.0.3 升级到 3.2.8                                          

方法：

新添加了一台服务器，逐步把每台机子进行硬盘，内存添加，再安装系统，再从要升级的服务器中，拷贝数据文件过来。这一切都还算胜利。

问题1：

每个节点300G,共600G 的数据，要拷贝3小时左右。也只有等了。 后来为了加快步骤，一台机子使用集群节点间数据自行同步的办法，灾难就来了，速度奇慢，10多个小时，才同步完成一个节点的数据（300G左右），建立索引这步就慢得不要不要的。。。。。看来升级到3.4是多么的重要。

问题2：

最后一台服务器中有个节点为主节点，还没升级完成时，通过mongos想连接，出现以下错误： <span style="font-size:18px;">mongos> use dmp switched to db dmp mongos> show tables; 2016-08-14T10:02:20.386+0800 E QUERY [thread1] Error: listCollections failed: { "code" : 133, "ok" : 0, "errmsg" : "could not find host matching read preference { mode: \"primary\", tags: [ {} ] } for set shard3" } : _getErrorWithCode@src/mongo/shell/utils.js:25:13 DB.prototype._getCollectionInfosCommand@src/mongo/shell/db.js:773:1 DB.prototype.getCollectionInfos@src/mongo/shell/db.js:785:19 DB.prototype.getCollectionNames@src/mongo/shell/db.js:796:16 shellHelper.show@src/mongo/shell/utils.js:754:9 shellHelper@src/mongo/shell/utils.js:651:15 @(shellhelp2):1:1 mongos> exit</span> 开始还一直往其它问题中去想，弄了半天也没想到什么好的办法。 后来同事问，是否有版本问题。我想也不可能啊。都是3.0 以上的版本。 后来想想，反正试试。 把主节点切到新版本（3.2.8）的一个节点上，再测试连接到router的接口上进行访问MONGODB,问题解决。

问题3：

</pre><blockquote><blockquote><pre name="code" class="javascript"><span style="font-size:18px;">[mongo@mds4 bin]$ ./mongo --port 28011 MongoDB shell version: 3.2.8 connecting to: 127.0.0.1:28011/test Server has startup warnings: 2016-08-13T06:33:25.817+0800 I CONTROL [initandlisten] 2016-08-13T06:33:25.817+0800 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'. 2016-08-13T06:33:25.817+0800 I CONTROL [initandlisten] ** We suggest setting it to 'never' 2016-08-13T06:33:25.817+0800 I CONTROL [initandlisten] 2016-08-13T06:33:25.817+0800 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'. 2016-08-13T06:33:25.817+0800 I CONTROL [initandlisten] ** We suggest setting it to 'never'</span> 处理方法 <span style="font-size:18px;"> [root@md5 ~]# cat /sys/kernel/mm/transparent_hugepage/defrag [always] madvise never [root@md5 ~]# echo never > /sys/kernel/mm/transparent_hugepage/enabled [root@md5 ~]# echo never > /sys/kernel/mm/transparent_hugepage/defrag [root@md5 ~]# cat /sys/kernel/mm/transparent_hugepage/defrag always madvise [never] [root@md5 ~]# cat /sys/kernel/mm/transparent_hugepage/enabled always madvise [never] [root@md5 ~]# </span>

问题4：

开始设置了oplogszie 为5G,同步完成后，例如出现如下错误： 2016-08-13T06:57:37.810+0800 I STORAGE [initandlisten] WARNING: the collection 'dp.aedm_advertis' lacks a unique index on _id. This index is needed for replication to function properly 2016-08-13T06:57:37.810+0800 I STORAGE [initandlisten] To fix this, you need to create a unique index on _id. See http://dochub.mongodb.org/core/build-replica-set-indexes 2016-08-13T06:57:37.810+0800 I STORAGE [initandlisten] WARNING: the collection 'dp.aedm_campaign' lacks a unique index on _id. This index is needed for replication to function properly 2016-08-13T06:57:37.810+0800 I STORAGE [initandlisten] To fix this, you need to create a unique index on _id. See http://dochub.mongodb.org/core/build-replica-set-indexes 开始以为在同步时，因为oplogSize不够，没有同步索引过来，但查询索引是有的。 后准备再修改oplogSize   后再同步一次呢。但取消 oplogSize  大小后，再重启 mongod ,再登录 后发现问题好了。具体原因还有待再分析 了。

结论：

      看来在做数据库升级时，还是要多准备一些，确认是否有版本兼容问题。前面在做各台服务器升级时，也没具体去测试那时是否有连接问题，同事已把WEB 服务关闭了。有可能那时都有这个问题。 如果真是上面所说。可能添加一个新版本的节点时，就要把primary 切换到新版本的节点来了。 并且先要把config server，router server 做升级。就象是从2.x 版本升级到 3.x 时一样。