总结遇到的几次MongoDB副本集初始化失败问题

前言:

在之前搭建MongoDB集群中,遇到过几次小问题引起的初始化副本集失败,都是之前初学时踩的坑,做个小结。

1、IP错误引起MongoDB副本集初始化失败

这个错误在另一篇文章已经描述过,这里略过不赘述。
详情见博客:IP错误引起MongoDB副本集初始化失败

2、PRIMARY与SECONDARY主机mongodb-keyfile文件内容不一致,导致在PRIMARY上添加副本集失败

问题描述:

搭建另外一个MongoDB副本集,主机和角色分配如下:

主机IP 角色 系统
131.10.11.106 PRIMARY centos7
131.10.11.111 SECONDARY centos7
131.10.11.114 SECONDARY centos7

MongoDB server version: 3.4.10.1

在PRIMARY上添加SECONDARY主机131.10.11.111,出现下面的报错:

mongotest:PRIMARY> rs.add("131.10.11.111:27017")
{
    "ok" : 0,
    "errmsg" : "Quorum check failed because not enough voting nodes responded; required 2 but only the following 1 voting nodes responded: 131.10.11.106:27017; the following nodes did not respond affirmatively: 131.10.11.111:27017 failed with Authentication failed.",
    "code" : 74,
    "codeName" : "NodeNotFound"
}

原因分析:

经过排查,发现131.10.11.111主机的mongodb-keyfile和主节点不一致,并且在131.10.11.111主机的配置文件mongo.conf文件没有配置安全认证,所以导致了初始化失败

解决方法:

1、将PRIMARY节点上的mongodb-keyfile文件复制到备节点131.10.11.111上,并且修改权限为400
2、并且修改配置文件/etc/mongodb/mongo.conf如下:

[[email protected] mongodb]# cat mongo.conf
systemLog:
   destination: file
   path: "/opt/mongodbdata/mongod.log"
   logAppend: true
storage:
   journal:
      enabled: true
   dbPath: /opt/mongodbdata
setParameter:
   enableLocalhostAuthBypass: true
processManagement:
   fork: true
   pidFilePath: "/opt/mongodbdata/mongod.pid"
replication:
   replSetName: mongotest
#添加下面几行:
security:
   authorization: enabled
   keyFile: "/etc/mongodb/mongodb-keyfile"
[[email protected] mongodb]#

重启131.10.11.111机器mongodb,然后重新在PRIMARY上执行 rs.add("131.10.11.111:27017"),成功。

3、备节点配置文件没有配置replSet,导致添加副本集失败

问题描述:

这个问题和问题2是在同一个环境中遇到的,在106主机上添加114主机的时候,报下面的错误:

mongotest:PRIMARY> rs.add("131.10.11.114:27017")
{
    "ok" : 0,
    "errmsg" : "Quorum check failed because not enough voting nodes responded; required 2 but only the following 1 voting nodes responded: 131.10.11.106:27017; the following nodes did not respond affirmatively: 131.10.11.114:27017 failed with not running with --replSet",
    "code" : 74,
    "codeName" : "NodeNotFound"
}

原因分析:

根据提示“the following nodes did not respond affirmatively: 131.10.11.114:27017 failed with not running with --replSe”,查看了114主机的配置文件mongo.conf,发现这是因为备节点上的配置文件里面没有配置副本集,所以无法添加

解决方法:

修改备节点的/etc/mongodb/mongo.conf配置文件如下,加上副本集配置:

[[email protected] mongodb]# cat mongo.conf
systemLog:
   destination: file
   path: "/opt/mongodbdata/mongod.log"
   logAppend: true
storage:
   journal:
      enabled: true
   dbPath: /opt/mongodbdata
setParameter:
   enableLocalhostAuthBypass: true
processManagement:
   fork: true
   pidFilePath: "/opt/mongodbdata/mongod.pid"
security:
   authorization: enabled
   keyFile: "/etc/mongodb/mongodb-keyfile"
replication:                           #加上副本集配置,
   replSetName: mongotest        #name要注意和主节点上保持一致
[[email protected] mongodb]#

重启131.10.11.114机器mongodb,然后重新在PRIMARY上执行 rs.add("131.10.11.114:27017"),成功

4、bindIp默认127.0.0.1,导致MongoDB副本集初始化失败

问题描述:

有一次搭建一个MongoDB副本集,主机和角色分配如下:

主机IP 角色 系统
10.0.0.101 PRIMARY centos7
10.0.0.102 SECONDARY centos7
10.0.0.103 SECONDARY centos7

MongoDB server version: 4.0.2
在PRIMARY主机10.0.0.101上加入SECONDARY主机10.0.0.102的时候出现这个错误:
添加从节点失败:

CrystalTest:PRIMARY> rs.add("10.0.0.102:27017")
{
    "operationTime" : Timestamp(1539054715, 1),
    "ok" : 0,
    "errmsg" : "Quorum check failed because not enough voting nodes responded; required 2 but only the following 1 voting nodes responded: 10.0.0.101:27017; the following nodes did not respond affirmatively: 10.0.0.102:27017 failed with Error connecting to 10.0.0.102:27017 :: caused by :: Connection refused",
    "code" : 74,
    "codeName" : "NodeNotFound",
    "$clusterTime" : {
        "clusterTime" : Timestamp(1539054715, 1),
        "signature" : {
            "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
            "keyId" : NumberLong(0)
        }
    }
}

原因分析:

看到 “failed with Error connecting to 10.0.0.102:27017 :: caused by :: Connection refused”的时候很疑惑,因为10.0.0.102主机上的27017端口是OK的,服务也能正常使用,防火墙什么的都是关掉了的,尝试在PRIMARY主机10.0.0.101主机上telnet,发现不通:

[[email protected] ~]# telnet 10.0.0.102 27017
Trying 10.0.0.102...
telnet: connect to address 10.0.0.102: Connection refused

然后到102主机上查看端口,发现bindIp是127.0.0.1,问题应该就是这里了。bindIp是127.0.0.1,因此导致了10.0.0.101主机连不过去:

[[email protected] ~]# netstat -tlunp|grep mongo
tcp        0      0 127.0.0.1:27017         0.0.0.0:*               LISTEN      1065/mongod    #显示的是127.0.0.1:27017

解决方法:

修改102主机的mongo.conf加入“bindIp: 0.0.0.0 ”,然后重启102主机的MongoDB

[[email protected] bin]# cat /etc/mongodb/mongo.conf
systemLog:
   destination: file
   path: "/opt/mongodbdata/mongod.log"
   logAppend: true
storage:
   journal:
      enabled: true
   dbPath: /opt/mongodbdata
setParameter:
   enableLocalhostAuthBypass: true
processManagement:
   fork: true
   pidFilePath: "/opt/mongodbdata/mongod.pid"
replication:
   replSetName: CrystalTest
security:
   authorization: enabled
   keyFile: "/etc/mongodb/mongodb-keyfile"
net:
  port: 27017
  bindIp: 0.0.0.0     #加入这一行

再查看端口:

[[email protected] mongodb]# netstat -tlunp|grep 27017
tcp        0      0 0.0.0.0:27017           0.0.0.0:*               LISTEN      3433/mongod           #变成了0 0.0.0.0:27017
[[email protected] mongodb]#

然后在101主机上telnet,可以连过去了:

[[email protected] ~]# telnet 10.0.0.102 27017
Trying 10.0.0.102...
Connected to 10.0.0.102.
Escape character is ‘^]‘.
^C^C

Connection closed by foreign host.
[[email protected] ~]# 

重新在PRIMARY主机10.0.0.101添加102主机,就成功了:

CrystalTest:PRIMARY> rs.add("10.0.0.102:27017")
{
    "ok" : 1,
    "operationTime" : Timestamp(1539056959, 1),
    "$clusterTime" : {
        "clusterTime" : Timestamp(1539056959, 1),
        "signature" : {
            "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
            "keyId" : NumberLong(0)
        }
    }
}

原文地址:http://blog.51cto.com/10950710/2296209

时间: 2024-10-25 02:17:27

总结遇到的几次MongoDB副本集初始化失败问题的相关文章

MongoDB副本集

简介 mongodb复制(replication)是将数据同步在多个服务器的过程.主节点记录在其上的所有操作oplog,从节点定期轮询主节点获取这些操作,然后对自己的数据副本执行这些操作,从而保证从节点的数据与主节点一致.复制提供了数据的冗余备份,并在多个服务器上存储数据副本,提高了数据的可用性,并保证数据的安全性.复制还允许您从硬件故障和服务中断中恢复数据. 而副本集(replica set)是从mongodb 1.6 提供的新功能,比复制功能要强大一些并增加了故障自动切换和自动修复成员节点,

Mongodb副本集实现

MongoDB副本集概述 以下图片摘自MongoDB官方文档:http://docs.mongodb.org/manual/core/replication-introduction/ Primary节点接收客户端所有的写操作,整个副本集只会有一个primary节点.MongoDB副本集提供严格的一致性.主节点将所有的操作写入一个叫oplog的capped collection(这个collection的大小一般为磁盘剩余空间的5%,不同的系统可能不一样,详见http://docs.mongod

zabbix使用Python实现监控MongoDB副本集状态

公司有 Windows 和 Linux 服务器,都搭建了 MongoDB 副本集,并且都要在 zabbix 平台中实现监控.Linux 系统直接使用 shell 脚本即可实现,但是 Windows 系统的不太好实现,我这里使用 Python 来实现.下面脚本同样适用于Linux系统(在 Windows server 2012 和 Centos7.3 系统都验证成功) 思路: 1.安装Python2.7 2.采用 Python 的 pymongo 模块来连接 mongodb 数据库,并认证授权 3

mongodb副本集维护

mongodb副本集维护主要工作: 1.查看副本集状态(集群状态.同步延迟.单个库的运行状态mongostate) 2.增删节点.停节点shutdown mongodb副本集集群同步机制 数据复制的目的是使数据得到最大的可用性,冗余,避免单点故障. 副本集中同一时刻只有一台服务器是可以写的,primary主库上写,从库同步数据 副本集主从复制也是异步同步的过程.slave从primary上获取日志,然后在自己身上完全顺序的执行日志记录的操作(该日志不记录查询操作,只记录更新操作).被同步的日志就

mongodb 副本集配置与说明

1,副本集的原理 副本集的原理与主从很相似,唯一不同的是,在主节点出现故障的时候,主从配置的从服务器不会自动的变为主服务器,而是要通过手动修改配置.但是副表集就不用,它会自动选出一台服务器做为主节点,从而保障系统的稳定性. 2,副本集新的主节点是怎么选举出来的呢 是通过bully算法来的,也就是一致性协议.具体如下 1):当主节点挂了后,副本集会获得其他从节点的最后更新时间与主服务做对比 2):如果所有从节点的最后更新时间都是很旧,那就选举停止 3):如果副本集中的大部分服务器挂了,包含主节点,

Mongodb副本集实现及读写分离

在前面的文章"Mongodb的主从模式搭建实例"中,我们对如何搭建一个主从结构的Mongodb服务器环境进行了简单的介绍.但是对于主从结构,Mongodb官方并不推荐我们使用了,可能是因为主从模式存在以下两个缺点: (1)主节点不可用之后,无法自动切换到从节点,无法确保业务访问的不间断性: (2)所有的读写操作都是对主节点的,造成主节点的访问压力较大: 因此,Mongodb为我们提供了另外一种推荐的使用方法,那就是使用副本集ReplicaSets.在这篇文章中简单描述一下副本集是如何实

MongoDB 副本集(类似高可用) [三]

MongoDB 副本集(类似高可用)1.节点类型standard:常规节点,它存储一份完整的数据副本,参与选举投票,有可能成为活跃节点.passive:存储了完整的数据副本,参与投票,不能成为活跃节点.arbiter:仲裁节点,只参与投票,不接收复制的数据,也不能成为活跃节点.2.参数说明--dbpath   数据文件路径--logpath  日志文件路径--port        端口号,默认是27017.我这里使用的也是这个端口号.--replSet   复制集的名字,一个replica s

mongodb副本集的内部机制(借鉴lanceyan.com)

针对mongodb的内部机制提出以下几个引导性的问题: 副本集故障转移,主节点是如何选举的?能否手动干涉下架某一台主节点. 官方说副本集数量最好是奇数,为什么? mongodb副本集是如何同步的?如果同步不及时会出现什么情况?会不会出现不一致性? mongodb的故障转移会不会无故自动发生?什么条件会触发?频繁触发可能会带来系统负载加重? Bully算法 mongodb副本集故障转移功能得益于它的选举机制.选举机制采用了Bully算法,可以很方便从分布式节点中选出主节点.一个分布式集群架构中一般

MongoDB副本集搭建及备份恢复

一.MongoDB副本集(repl set)介绍 早起版本使用master-slave,一主一从和MySQL类似,但slave在此架构中为只读,当主库宕机后,从库不能自动切换为主: 目前已经淘汰了master-slave模式,改为副本集,这种模式下有一个主(primary),和多个从(secondary),只读,支持给他们设置权重,当主宕掉后,权重最高的从切换为主: 在此架构中还可以建立一个仲裁(arbiter)的角色,它只负责裁决,而不存储数据 在此架构中读写数据都是在主上,要想实现负载均衡的