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

本文涉及的产品
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
简介:
今天在给一组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里面配置安全选项。
目录
相关文章
|
缓存 监控 NoSQL
【MongoDB 专栏】MongoDB 的变更流(Change Streams)应用
【5月更文挑战第11天】MongoDB的变更流是实时监控数据库动态的机制,允许应用程序订阅并响应文档的插入、更新和删除事件。它提供实时性、灵活性和解耦性,适用于数据同步、实时通知、缓存更新等多种场景。然而,使用时需注意性能、错误处理和版本兼容性。随着技术发展,变更流将在构建智能实时系统中扮演更重要角色,为数据处理带来新机遇。
537 1
【MongoDB 专栏】MongoDB 的变更流(Change Streams)应用
|
NoSQL MongoDB 数据安全/隐私保护
Flink CDC支持MongoDB的CDC(Change Data Capture)连接器
Flink CDC支持MongoDB的CDC(Change Data Capture)连接器
443 4
|
NoSQL MongoDB 数据库
【MongoDB基础原理】Change Streams 生产建议
MongoDB从3.6版本开始提供了Change Stream特性,通过该特性,应用程序可以实时的订阅特定集合、库、或整个集群的数据变更事件,相比该特性推出之前通过监听oplog的变化来实现对数据变更的感知,非常的易用,该特性同时支持副本集和集群场景。
【MongoDB基础原理】Change Streams 生产建议
|
存储 JSON NoSQL
暂缓MongoDB 4.4.2 、4.4.3、 4.4.4版本升级: 存在严重Bug
暂缓MongoDB 4.4.2 、4.4.3、 4.4.4版本升级: 存在严重Bug
361 0
暂缓MongoDB 4.4.2 、4.4.3、 4.4.4版本升级: 存在严重Bug
|
域名解析 存储 供应链
MongoDB 4.2 内核解析 - Change Stream
本文将为大家讲解 MongoDB 4.2 的 Change Stream 功能,接下来将分别从其功能、使用以及内部实现进行详细介绍。
1105 0
MongoDB 4.2 内核解析 - Change Stream
|
监控 NoSQL JavaScript
Java和Node.js实战 MongoDB 4.x 新特性:Change Streams 变化流
MongoDB 4.0 Change Streams增强新特性,我们可以跟踪单个集合Colletion、数据库或部署集群的数据库和集合中的所有变化。
|
存储 NoSQL
MongoDB Primary 为何持续出现 oplog 全表扫描?
线上某 MongoDB 复制集实例(包含 Primary、Secondary、Hidden 3个节点 ),Primary 节点突然 IOPS 很高,调查后发现,其中 Hidden 处于 RECOVERING 状态,同时 Priamry 上持续有一全表扫描 oplog 的操作,正是这个 oplog 的 COLLSCAN 导致IO很高。