mongoDB3.2.8 升级遇到的问题

最新推荐文章于 2022-10-09 10:38:04 发布

边城cn

最新推荐文章于 2022-10-09 10:38:04 发布

阅读量3.6k

点赞数

分类专栏： NOSQL 文章标签： MONGODB

本文链接：https://blog.csdn.net/miyatang/article/details/52203740

版权

NOSQL 专栏收录该内容

55 篇文章 0 订阅

订阅专栏

环境：

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 ,再登录后发现问题好了。具体原因还有待再分析了。