a mongodb 1.8.1 unauthorized BUG when I change replicaSet config in Primary

今天在给一组mongoDB replicaSet修改配置的时候,遇到一个BUG。

环境是这样的:

3台服务器组成的3 full nodes replicaSet.

由于其中一台服务器配置比较差,准备调整"priority" : 0

让这台节点不会自动转会为primary.

引起BUG的是开启了keyFile(1.8.1使用keyFile来实现member之间的认证),也就是replicaSet的authorization.(看样子目前replicaSet的authorization还是不稳定啊。)

修改配置如下:

首先在primary修改配置

digoal:PRIMARY> conf=rs.conf()

{

        "_id" : "digoal",

        "version" : 1,

        "members" : [

                {

                        "_id" : 0,

                        "host" : "192.168.xxx.xxx:5281"

                },

                {

                        "_id" : 1,

                        "host" : "192.168.xxx.xxx:5281"

                },

                {

                        "_id" : 2,

                        "host" : "192.168.xxx.xxx:5281"

                }

        ]

}

digoal:PRIMARY> conf.members[1].priority=0

0

digoal:PRIMARY> conf

{

        "_id" : "digoal",

        "version" : 1,

        "members" : [

                {

                        "_id" : 0,

                        "host" : "192.168.xxx.xxx:5281"

                },

                {

                        "_id" : 1,

                        "host" : "192.168.xxx.xxx:5281",

                        "priority" : 0

                },

                {

                        "_id" : 2,

                        "host" : "192.168.xxx.xxx:5281"

                }

        ]

}

digoal:PRIMARY> rs.reconfig(conf)

digoal:PRIMARY> db.auth("digoal","digoalpwd")

1

digoal:PRIMARY> rs.conf()

{

        "_id" : "digoal",

        "version" : 2,

        "members" : [

                {

                        "_id" : 0,

                        "host" : "192.168.xxx.xxx:5281"

                },

                {

                        "_id" : 1,

                        "host" : "192.168.xxx.xxx:5281",

                        "priority" : 0

                },

                {

                        "_id" : 2,

                        "host" : "192.168.xxx.xxx:5281"

                }

        ]

}

从主节点来看,配置已经生效了。

但是在任何一个SLAVE节点,都没有生效

digoal:SECONDARY> rs.conf()

{

        "_id" : "digoal",

        "version" : 1,

        "members" : [

                {

                        "_id" : 0,

                        "host" : "192.168.xxx.xxx:5281"

                },

                {

                        "_id" : 1,

                        "host" : "192.168.xxx.xxx:5281"

                },

                {

                        "_id" : 2,

                        "host" : "192.168.xxx.xxx:5281"

                }

        ]

}

从SLAVE节点的日志来看,

Sat May 21 07:44:48 [rs Manager] replset msgReceivedNewConfig version: version: 3

Sat May 21 07:44:48 [rs Manager] replSet info saving a newer config version to local.system.replset

Sat May 21 07:44:48 [rs Manager] Server::doWork task:rs Manager exception:unauthorized db:local lock type:2 client:(NONE)

Sat May 21 07:44:49 [conn3] run command admin.$cmd { replSetHeartbeat: "digoal", v: 1, pv: 1, checkEmpty: false, from: "192.168.175.71:5281" }

Sat May 21 07:44:49 [conn3] query admin.$cmd ntoreturn:1 command: { replSetHeartbeat: "digoal", v: 1, pv: 1, checkEmpty: false, from: "192.168.175.71:5281" } reslen:132 0ms

Sat May 21 07:44:49 [conn4] run command admin.$cmd { replSetHeartbeat: "digoal", v: 3, pv: 1, checkEmpty: false, from: "192.168.175.67:5281" }

Sat May 21 07:44:49 [conn4] query admin.$cmd ntoreturn:1 command: { replSetHeartbeat: "digoal", v: 3, pv: 1, checkEmpty: false, from: "192.168.175.67:5281" } reslen:132 0ms

从这上面来看,replicaSet的节点之间已经失去认证了。

不修改配置的话不会这样,一切正常。

后来查到,mongodb告知这是一个BUG。修复办法是升级到1.8.2,1.9.0

于是就找来1.8.2的版本,但是问题更蹊跷。

在起1.8.2的时候连库都起不来

mmongo@db-digoal-> mongod -h

Sat May 21 08:07:52 Invalid access at address: 0x1

Sat May 21 08:07:52 Got signal: 11 (Segmentation fault).

Sat May 21 08:07:52 Backtrace:

0x8a66b9 0x8a6c90 0x314600eb10 0x3145879b60 0x56d3d3 0x8a5149 0x8ad2a3 0x314581d994 0x4e1009 

 mongod(_ZN5mongo10abruptQuitEi+0x399) [0x8a66b9]

 mongod(_ZN5mongo24abruptQuitWithAddrSignalEiP7siginfoPv+0x220) [0x8a6c90]

 /lib64/libpthread.so.0 [0x314600eb10]

 /lib64/libc.so.6(strlen+0x10) [0x3145879b60]

 mongod(_ZN5mongo13show_warningsEv+0x363) [0x56d3d3]

 mongod(_Z14show_help_textN5boost15program_options19options_descriptionE+0x9) [0x8a5149]

 mongod(main+0x10d3) [0x8ad2a3]

 /lib64/libc.so.6(__libc_start_main+0xf4) [0x314581d994]

 mongod(__gxx_personality_v0+0x3a1) [0x4e1009]

Sat May 21 08:07:52 dbexit: 

Sat May 21 08:07:52 File I/O errno:29 Illegal seek

shutdown: going to close listening sockets...

Sat May 21 08:07:52 shutdown: going to flush diaglog...

Sat May 21 08:07:52 shutdown: going to close sockets...

Sat May 21 08:07:52 shutdown: waiting for fs preallocator...

Sat May 21 08:07:52 shutdown: closing all files...

Sat May 21 08:07:52 closeAllFiles() finished

Sat May 21 08:07:52 dbexit: really exiting now

于是只能放弃升级到1.8.2,暂时将keyFile的参数去掉,用1.8.1来起,配置得以同步到SLAVE节点。恢复正常。

再在服务器的iptables里面配置安全选项。

时间: 2024-10-23 03:05:18

a mongodb 1.8.1 unauthorized BUG when I change replicaSet config in Primary的相关文章

mongoDB nagios plugin (check_mongodb.py) BUG resolve

昨天一位同事问我现在我们的mongoDB在用什么做监控, 实在是惭愧, 一直没有对mongoDB进行比较细节的监控.  仅仅是监控了服务器的一些性能指标. 今天赶紧看了一下mongoDB手册中关于监控的章节.  下面是根据mongoDB官方推荐的几种监控方式之一, 结合我们正在使用的nagios进行的配置. 前提条件, 1. 需要nagios服务端 2. 在mongoDB所在的服务器需要安装nagios agent 3. 在mongoDB所在的服务器需要python >=2.4的版本 , 我这里

MongoDB 复制集(Replica Set)

复制集(replica Set)或者副本集是MongoDB的核心高可用特性之一,它基于主节点的oplog日志持续传送到辅助节点,并重放得以实现主从节点一致.再结合心跳机制,当感知到主节点不可访问或宕机的情形下,辅助节点通过选举机制来从剩余的辅助节点中推选一个新的主节点从而实现自动切换.这个特性与MySQL MHA实现原理一样.本文主要描述MongoDB复制集并给出创建复制集示例以及完成自动切换. 一.复制集相关概念 复制集 复制是在多台服务器之间同步数据的过程,由一组Mongod实例(进程)组成

php操作MongoDB类实例

 本文实例讲述了php操作MongoDB类的方法.分享给大家供大家参考.具体如下: 1. MyMongo.php文件: ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66

MongoDB管理:慎用local、admin数据库

MongoDB副本集默认会创建local.admin数据库,local数据库主要存储副本集的元数据,admin数据库则主要存储MongoDB的用户.角色等信息. 慎用local数据库 local数据库,从名字可以看出,它只会在本地存储数据,即local数据库里的内容不会同步到副本集里其他节点上去:目前local数据库主要存储副本集的配置信息.oplog信息,这些信息是每个Mongod进程独有的,不需要同步到副本集种其他节点. 在使用MongoDB时,重要的数据千万不要存储在local数据库中,否

MongoDB · 特性分析 · 索引原理

为什么需要索引? 当你抱怨MongoDB集合查询效率低的时候,可能你就需要考虑使用索引了,为了方便后续介绍,先科普下MongoDB里的索引机制(同样适用于其他的数据库比如mysql). mongo-9552:PRIMARY> db.person.find() { "_id" : ObjectId("571b5da31b0d530a03b3ce82"), "name" : "jack", "age" :

MongoDB 3.4 功能改进一览

MongoDB 3.4 已经发布,本文主要介绍 3.4 版本在功能特性上做的改进,内容翻译自 [https://docs.mongodb.com/manual/release-notes/3.4/?_ga=1.74729233.2005306875.1453858874). 分片集群(Sharded Cluster) Membership Awareness MongoDB 3.4里,分片集群的所有组件,Config server.mongod.mongos 都能相互感知整个分片集群的存在,了解

PHP操作MongoDB配置与学习笔记

PHP操作MongoDB配置与学习笔记有需要的朋友可参考参考.Mongo主要解决的是海量数据的访问效率问题,根据官方的文档,当数据量达到50GB以上的时候,Mongo的数据库访问速度是MySQL的 10倍以上 2,安装(windows only) 到官网下载对应的包 解压到d:mongodb 创建d:mongodbdata放置数据文件 3,运行mongodb d:mongodbbin下有一些可执行文件,其中mongod.exe是服务器端,mongo.exe是客户端. 运行cmd,输入 d:mon

全新版本MongoDB数据存储席卷物联网

本文首先对物联网进行了模型抽象,着重和大家剖析了MongoDB解决方案,包括文档模型.高可用复制集.分片集群和Aggregation&MapReduce,最后分享了全新的MongoDB特性. 以下为内容整理: MongoDB是文档型数据库,其核心的三大优势是灵活文档模型 .高可靠复制集. 高可扩展分片集群.在最新的 DB Engine Rank 的排名中,MongoDB 排在第4,是非关系型数据库领域的领头羊. 物联网模型抽象 物联网离我们越来越近,这主要得益于云计算和移动互联网技术的发展.物联

【Mongodb】Sharding 集群配置

mongodb的sharding集群由以下3个服务组成: Shards  Server: 每个shard由一个或多个mongod进程组成,用于存储数据 Config  Server: 用于存储集群的Metadata信息,包括每个Shard的信息和chunks信息 Route   Server: 用于提供路由服务,由Client连接,使整个Cluster看起来像单个DB服务器 另外,Chunks是指MongoDB中一段连续的数据块,默认大小是200M,一个Chunk位于其中一台Shard服务器上