docker中部署mongodb副本集

1.基本信息如下

服务器地址 192.168.73.129

副本集名称 rs

容器节点及端口映射

m0 37017:27017

m1 47017:27017

m2 57017:27017

注:机器环境安装docker

2.部署步骤

2.1下载mongo镜像

docker pull mongo

2.2 启动三个节点

docker run --name m0 -p 37017:27017 -d mongo --replSet "rs"

docker run --name m1 -p 47017:27017 -d mongo --replSet "rs"

docker run --name m2 -p 57017:27017 -d mongo --replSet "rs"

docker ps -a   //查看启动的容器

2.3 连接任意一个节点,进行副本集配置

进入其中一个容器:docker exec -it de242cc5fa5a  /bin/bash

连接三个节点中的任意一个,注意ip地址为宿主机ip,我当前的为192.168.73.129

mongo --host 192.168.73.129 --port 37017

此时已连接到m0节点,进行副本集配置

var config={
     _id:"rs",
     members:[
         {_id:0,host:"192.168.73.129:37017"},
         {_id:1,host:"192.168.73.129:47017"},
         {_id:2,host:"192.168.73.129:57017"}
]};
rs.initiate(config)

响应应该类似下面,注意此时命令提示符已经发生变化,由原来的 > 变成了 rs:SECONDARY>

{
    "ok" : 1,
    "operationTime" : Timestamp(1522810920, 1),
    "$clusterTime" : {
        "clusterTime" : Timestamp(1522810920, 1),
        "signature" : {
            "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
            "keyId" : NumberLong(0)
        }
    }
}

2.4查看副本集配置信息

rs:SECONDARY> rs.conf()
{
    "_id" : "rs",
    "version" : 1,
    "protocolVersion" : NumberLong(1),
    "writeConcernMajorityJournalDefault" : true,
    "members" : [
        {
            "_id" : 0,
            "host" : "192.168.73.129:37017",
            "arbiterOnly" : false,
            "buildIndexes" : true,
            "hidden" : false,
            "priority" : 1,
            "tags" : {

            },
            "slaveDelay" : NumberLong(0),
            "votes" : 1
        },
        {
            "_id" : 1,
            "host" : "192.168.73.129:47017",
            "arbiterOnly" : false,
            "buildIndexes" : true,
            "hidden" : false,
            "priority" : 1,
            "tags" : {

            },
            "slaveDelay" : NumberLong(0),
            "votes" : 1
        },
        {
            "_id" : 2,
            "host" : "192.168.73.129:57017",
            "arbiterOnly" : false,
            "buildIndexes" : true,
            "hidden" : false,
            "priority" : 1,
            "tags" : {

            },
            "slaveDelay" : NumberLong(0),
            "votes" : 1
        }
    ],
    "settings" : {
        "chainingAllowed" : true,
        "heartbeatIntervalMillis" : 2000,
        "heartbeatTimeoutSecs" : 10,
        "electionTimeoutMillis" : 10000,
        "catchUpTimeoutMillis" : -1,
        "catchUpTakeoverDelayMillis" : 30000,
        "getLastErrorModes" : {

        },
        "getLastErrorDefaults" : {
            "w" : 1,
            "wtimeout" : 0
        },
        "replicaSetId" : ObjectId("5b3c937896d237ac24a0648e")
    }
}
rs:SECONDARY> 

2.5 查看副本集状态

rs:SECONDARY> rs.status()
{
    "set" : "rs",
    "date" : ISODate("2018-07-04T09:45:38.110Z"),
    "myState" : 2,
    "term" : NumberLong(1),
    "syncingTo" : "192.168.73.129:37017",
    "syncSourceHost" : "192.168.73.129:37017",
    "syncSourceId" : 0,
    "heartbeatIntervalMillis" : NumberLong(2000),
    "optimes" : {
        "lastCommittedOpTime" : {
            "ts" : Timestamp(1530697530, 1),
            "t" : NumberLong(1)
        },
        "readConcernMajorityOpTime" : {
            "ts" : Timestamp(1530697530, 1),
            "t" : NumberLong(1)
        },
        "appliedOpTime" : {
            "ts" : Timestamp(1530697530, 1),
            "t" : NumberLong(1)
        },
        "durableOpTime" : {
            "ts" : Timestamp(1530697530, 1),
            "t" : NumberLong(1)
        }
    },
    "lastStableCheckpointTimestamp" : Timestamp(1530697480, 1),
    "members" : [
        {
            "_id" : 0,
            "name" : "192.168.73.129:37017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 967,
            "optime" : {
                "ts" : Timestamp(1530697530, 1),
                "t" : NumberLong(1)
            },
            "optimeDurable" : {
                "ts" : Timestamp(1530697530, 1),
                "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2018-07-04T09:45:30Z"),
            "optimeDurableDate" : ISODate("2018-07-04T09:45:30Z"),
            "lastHeartbeat" : ISODate("2018-07-04T09:45:36.221Z"),
            "lastHeartbeatRecv" : ISODate("2018-07-04T09:45:36.296Z"),
            "pingMs" : NumberLong(0),
            "lastHeartbeatMessage" : "",
            "syncingTo" : "",
            "syncSourceHost" : "",
            "syncSourceId" : -1,
            "infoMessage" : "",
            "electionTime" : Timestamp(1530696579, 1),
            "electionDate" : ISODate("2018-07-04T09:29:39Z"),
            "configVersion" : 1
        },
        {
            "_id" : 1,
            "name" : "192.168.73.129:47017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 967,
            "optime" : {
                "ts" : Timestamp(1530697530, 1),
                "t" : NumberLong(1)
            },
            "optimeDurable" : {
                "ts" : Timestamp(1530697530, 1),
                "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2018-07-04T09:45:30Z"),
            "optimeDurableDate" : ISODate("2018-07-04T09:45:30Z"),
            "lastHeartbeat" : ISODate("2018-07-04T09:45:36.221Z"),
            "lastHeartbeatRecv" : ISODate("2018-07-04T09:45:36.219Z"),
            "pingMs" : NumberLong(0),
            "lastHeartbeatMessage" : "",
            "syncingTo" : "192.168.73.129:37017",
            "syncSourceHost" : "192.168.73.129:37017",
            "syncSourceId" : 0,
            "infoMessage" : "",
            "configVersion" : 1
        },
        {
            "_id" : 2,
            "name" : "192.168.73.129:57017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 2153,
            "optime" : {
                "ts" : Timestamp(1530697530, 1),
                "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2018-07-04T09:45:30Z"),
            "syncingTo" : "192.168.73.129:37017",
            "syncSourceHost" : "192.168.73.129:37017",
            "syncSourceId" : 0,
            "infoMessage" : "",
            "configVersion" : 1,
            "self" : true,
            "lastHeartbeatMessage" : ""
        }
    ],
    "ok" : 1,
    "operationTime" : Timestamp(1530697530, 1),
    "$clusterTime" : {
        "clusterTime" : Timestamp(1530697530, 1),
        "signature" : {
            "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
            "keyId" : NumberLong(0)
        }
    }
}
rs:SECONDARY> 

2.6 客户端工具连接

原文地址:https://www.cnblogs.com/cowboys/p/9264494.html

时间: 2024-08-03 03:00:01

docker中部署mongodb副本集的相关文章

MongoDB副本集(一主两从)读写分离、故障转移功能环境部署记录

Mongodb是一种非关系数据库(NoSQL),非关系型数据库的产生就是为了解决大数据量.高扩展性.高性能.灵活数据模型.高可用性.MongoDB官方已经不建议使用主从模式了,替代方案是采用副本集的模式.主从模式其实就是一个单副本的应用,没有很好的扩展性和容错性,而Mongodb副本集具有多个副本保证了容错性,就算一个副本挂掉了还有很多副本存在,主节点挂掉后,整个集群内会实现自动切换. Mongodb副本集的工作原理客户端连接到整个Mongodb副本集,不关心具体哪一台节点机是否挂掉.主节点机负

MongoDB集群部署(副本集模式)

一.需求背景1.现状描述(1).针对近期出现的mongodb未授权的安全问题,导致mongodb数据会被非法访问.应安全平台部的要求,需要对所有mongodb进行鉴权设置,目前活动侧总共有4台,用于某XX产品: (2).某XX产品用到4台mongodb,属于2015年机房裁撤的范围: (3).早期的4台mongodb采用是的M1机型,同时在架构上采取了路由分片的模式.从目前来看,无论是数据量上,还是访问量上,都比较小,在资源上有点浪费,在架构上属于过早设计. 而本次新建的mongodb集群,采用

mongodb副本集搭建过程中的问题和解决技巧

在我以往的认知中,一个系统一旦正式上线,多半不会轻易的迁移服务器,尤其是那种涉及到多个关联应用,涉及到多台硬件服务器的系统,因为这种迁移将是牵一发而动全身的. 但是,却仍然有这种情况存在,就如我这几天主要负责的事,就是一个系统的全部服务器迁移中的部分机器迁移,还有一部分由别人负责. 这个系统涉及到flume数据采集,storm数据分析,rabbitmq消息分发,ehcache缓存提升系统性能,mongodb副本集存储数据,tomcat管理系统应用等,架构基本如下: 而这里我主要负责的是rabbi

7条命令在docker中部署Mesos集群

7条命令在docker中部署Mesos集群 所有使用的Docker容器构建文件是有也.您可以在本地构建每个容器或只使用位于Docker Hub预构建的容器.下面的命令会自动下载所需的预建的容器为您服务.ZooKeeper?-?https://registry.hub.docker.com/u/garland/zookeeper/Meso Master?-?https://registry.hub.docker.com/u/garland/mesosphere-docker-mesos-maste

MongoDB 副本集的相关概念【转】

一.副本集基本概念 副本集(replica set) MongoDB的replica set是一个mongod进程实例簇,数据在这个簇中相互复制,并自动进行故障切换. MongoDB的数据库复制增加了冗余,确保了高可用性,简化了管理任务如备份,并且增加了读能力.大多数产品部署都使用了复制.MongoDB中primary处理写操作,其它进行复制的成员则是secondaries. 一个副本集可以最多支持12个成员,但是只有7个成员可以参与投票. 注:MongoDB同时提供了传统的master/sla

MongoDB副本集功能及节点属性梳理

副本集的主要功能 副本集是MongoDB高可用的基础,其主要作用 归纳为以下几点: (1)高可用,防止设备(服务器.网络)故障.提供自动FailOver功能. (2)无需配置高可用性虚拟节点:无论是SQL Server 的AlwaysOn 还是 MySQL 的 MHA方案 都需要有可用性组 或集群的虚拟IP,要求程序连接使用这个虚拟IP.但是MongoDB 副本集不需要  配置虚拟IP,而是当我们在连接字符串中指定replicaSet 参数设置 后,会自动识别查找master节点.这样 可以省去

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

MongoDB副本集的工作原理

在MongoDB副本集中,主节点负责处理客户端的读写请求,备份节点则负责映射主节点的数据. 备份节点的工作原理过程可以大致描述为,备份节点定期轮询主节点上的数据操作,然后对自己的数据副本进行这些操作,从而保证跟主节点的数据同步. 至于主节点上的所有数据库状态改变的操作,都会存放在一张特定的系统表中.备份节点则是根据这些数据进行自己的数据更新. oplog 上面提到的数据库状态改变的操作,称为oplog(operation log,主节点操作记录).oplog存储在local数据库的"oplog.