您的当前位置:首页正文

MongoDB 搭建副本集

2023-11-11 来源:帮我找美食网

副本集(Replica Set)是一组MongoDB实例组成的集群,由一个主(Primary)服务器和多个备份(Secondary)服务器构成。通过Replication,将数据的更新由Primary推送到其他实例上,在一定的延迟之后,每个MongoDB实例维护相同的数据集副本。通过维护冗余的数据库副本,能够实现数据的异地备份,读写分离和自动故障转移。

一,MongoDB版本和环境

在Windows上创建包含三个节点的副本集,使用的环境:

  • 数据库:MongoDB 版本 3.2.9
  • Server 环境:Windows Server 2012 R2
  • 可视化编程环境:Robomongo 版本 0.08.4
  • 三台Windows Server:srv1,srv2,srv3
  • 二,拓扑结构分析

    创建一个Replica Set,包含三个成员:一个Primary 成员和两个Secondary 成员,Primary用于处理客户端请求,Secondary用于保存Primary的数据副本。客户端Application 在 Primary 节点上进行读写操作,通过Replication的异步同步机制,将数据操作同步到 Secondary 成员,在一定的延迟之后,三个成员拥有相同的数据集。

    技术分享

    理论上,每个成员可以分布在不同的数据中心机房内,这些数据中心可能相距甚远,实现数据的异地备份;可以设置Primary 节点只负责写入操作,而使Secondary节点负责读取操作,实现数据集的读写分离;如果Primary 连接中断超过10s,其他节点会自动选举出一个Primary 节点,负责响应客户端Application的请求,实现数据的自动故障转移。

    技术分享

    三,技术原理说明

    1,以Replica Set模式启动MongoDB实例

    MongoDB Instance有两种不同的启动方式:单机模式(Standalone)和副本集模式(Replica Set),在启动mongod时,如果设置 replSet 参数,那么MongoDB 实例以副本集模式启动;如果不设置replSet 参数,那么MongoDB以单机模式启动。

    单机实例是指运行在服务器上的一个mongod 进程,该进程不是任何一个Replica Set的成员,因此,单机实例不能自动故障转移,在产品环境中,风险很高,如果服务器崩溃了,客户端App至少在一段时间内不可访问,如果硬件出现问题,可能会造成数据的永久丢失。建议,使用Replica Set,至少保留两份数据集副本。

    2,选举Primary成员

    在Replica Set中有两种成员:Primary成员和Secondary成员,一个Replica Set只能有一个Primary成员,但可以有多个Secondary成员。Primary用于处理客户端请求,Secondary用于保存Primary的数据副本。如果Primary崩溃了,Replica Set探测到Primary不可访问,将启动自动故障转移进程,从剩下的Secondary成员中,投票选举出一个成员作为Primary,接收和处理客户端的请求。

    选举Primary成员时,使用“大多数”和“一票否决”原则。在Replica Set中,每个成员只能要求自己被选举为Primary节点。当一个Secondary成员无法与Primary成员连通时,该成员就会发起选举,请求其他成员将自己选举为Primary成员,只有得到“大多数”成员的支持,该成员才能被选举为Primary成员;只要有一个成员否决,选举就会取消。

    不是每一个成员都有投票选举的权利,在一个Replica Set中,最多有7个成员用于投票选举的权利,Primary成员是由这7个成员选举出来的。有投票权利的成员,其属性:"votes" 是1;若为0,表示该成员没有投票权利。

    3,操作日志

    MongoDB使用操作日志(oplog)来实现复制(Replication)功能,oplog包含了Primary成员的每一个更新操作,通过将oplog传递到其他Secondary成员中,在其他成员中重做(redo)已经提交的操作,实现数据的异步同步。Replica Set中的每个成员都维护着自己的oplog,记录着每一个从Primary成员复制操作的数据。复制操作的过程是先复制数据,再将操作写入到oplog中。如果某一个成员在执行操作时失败,当该成员重启之后,自动从oplog中最后一个操作进行同步。由于复制操作的过程是先复制数据,再写入oplog,该成员可能会在已经同步的数据上再次执行复制操作,MongoDB在设计oplog时,就考虑到这种情况:将oplog中的同一个操作执行多次,与执行一次的结果是一样的。

    oplog保存的是对每个doc的更新操作日志,如果一个命令只更新一个doc,那么Replication进程向oplog插入一条日志;如果一个命令更新多个doc,那么Replication进程向oplog插入多条日志,每一条日志只更新一个doc。

    oplog的大小是固定的,只能保存特定数量的操作日志,如果Primary成员更新的数据量特别大,oplog很快就被填满,Secondary来不及同步数据,Primary成员就将oplog中的日志,这样,Secondary成员就会变成陈旧的(Stale)。建议,让Primary成员使用比较大的oplog,保存足够多的操作日志。

    四,创建配置文档

    1,创建mongod 启动的配置文件

    在每台server上创建配置文件,将配置文件存放在目录C:data中。在同一个Replica Set中的所有成员必须有相同的Replica Set Name,这里设置为“rs0”。

    技术分享
    --srv1 config_file_name:rs0_1.confdbpath=C:datadbdb_rs0logpath=C:datadbdb_rs0s0_1.logport=40001replSet=rs0--srv2   config_file_name:rs0_2.confdbpath=C:datadbdb_rs0logpath=C:datadbdb_rs0s0_2.logport=40002replSet=rs0--srv3  config_file_name:rs0_3.confdbpath=C:datadbdb_rs0logpath=C:datadbdb_rs0s0_3.logport=40003replSet=rs0
    技术分享

    配置参数含义:

  • replSet:设置Replica Set的name,在各个配置文件中,其值必须相同。
  • dbpath:MongoDB用于存储数据的目录,默认值是C:datadb
  • logpath:用于记录mongod的日志数据
  • port:指定MongoDB监听的端口,默认值是27017
  • 2,以配置文件方式启动mongod

    一般情况下,mongod的参数值是不变的,将这些参数写入到配置文件中,能够简化MongoDB的管理。

    mongod 命令有参数:--config 或 -f,用于引用配置文件。

    技术分享
    --srv1mongod -f C:datas0_1.conf--srv2mongod -f C:datas0_2.conf--srv3mongod -f C:datas0_3.conf
    技术分享

    3,启动mongo shell

    在任意一台Server上打开三个mongo shell,使用参数 --host 指定Server Name,使用 --port 指定端口号。由于mongod没有使用默认的监听端口 27017,因此,必须使用 在mongo shell中使用 --port参数显式指定监听的Port。

    技术分享
    --connect srv1mongo --host srv1 --port 40001--connect srv2mongo --host srv2 --port 40002--connect srv3 mongo --host srv3 --port 40003
    技术分享

    五,配置Replica Set

    在不同的Server上运行不同的MongoDB Instance,但是,每个mongod 都不知道其他mongod的存在,为了让每个mongod能够感知彼此的存在,需要配置Replica set,增加成员。

    1,使用配置文档为Replica Set 增加成员

    在srv1的mongo shell中,创建配置文档,调用rs.initiate()函数,按照配置文档来初始化Replica Set。

    技术分享
    conf={ "_id" : "rs0", "members" : [ { "_id" : 0, "host" : "srv1:40001" }, { "_id" : 1, "host" : "srv2:40002" }, { "_id" : 2, "host" : "srv3:40003" } ]}rs.initiate(conf)
    技术分享

    在配置doc中,使用"_id" : "rs0" 指定Replica Set的name,members数组指定 Replica Set的成员的ID 和 host(“host:port”)。等到所有成员配置完成之后,Replica Set 会自动选举出一个Primary 节点,两个Secondary 节点。在Primary 节点上进行更新操作,就能同步到Secondary 节点了。

    2,修改Replica Set

    如果以rs.initiate()方式初始化Replica Set,那么MongoDB以默认配置文档初始化Replica Set,可以通过add()函数增加成员。

    2.1 向Replica Set中增加一个成员

    rs.add("host:port")

    2.2 从Replica Set中删除一个成员

    rs.remove("host")

    2.3 查看Replica Set的配置

    rs.conf()

    2.4 重新配置Replica Set

    技术分享
    var conf=rs.conf()conf.members[1].priority =5--at primary memberrs.reconf(conf)--at secondary memberrs.reconf(conf,{force:true})
    技术分享

    2.5 查看Replica Set的状态

    rs.status()

    六,维护Replica Set

    1,查看Replica Set的配置信息

    rs.conf()

    配置文档主要分为三块:Replica Set 的ID和 Version,Members数组 和 Settings,下面是经过简化的配置信息。

    技术分享
    { "_id" : "rs0", "version" : 202997, "members" : [ { "_id" : 1, "host" : "srv1:40001", "arbiterOnly" : false, "hidden" : false, "priority" : 5, "votes" : 1 }, {...} ], "settings" : { ..... }}
    技术分享

    Replica Set的ID字段唯一标识一个Replica Set,每一个Replica Set都有一个自增的版本号,由Version字段标识,标识Replica Set的不同版本。version字段的初始值是1,每次修改Replica Set的配置时,version字段都会自增。

    Settings 字段的值是应用到Replica Set中所有成员的配置信息。

    最关键的是members数组的字段,标识每个成员的配置信息。

  • arbiterOnly:0或1,标识一个仲裁(arbiter),Arbiter的唯一作用是参与Primary的选举,Arbiter不保存数据,不会为client提供服务,它存在的意义就是为了选举Primary。
  • hidden:0或1,表示该成员是不是隐藏成员,Hidden成员的主要作用是备份数据,可以使用性能较差的服务器作为Hidden成员。Hidden成员不会接收Client的请求,也不会成为Primary。在设置Hidden成员时,必须设置members[n].priorty属性为0;
  • priority:数值类型,用于设置成员成为Primary的优先级。priority越高的成员,越有机会成为Primary。如果priority=0,那么该成员永远不会成为Primary。
  • votes:1或0,表示该成员的投票的数量,在每个Replica Set中,最多有7个成员,其votes属性值是1。votes 属性是1的成员(voting members)拥有选举Primary的权利。一个成员要想成为一个Primary,那么必须获得voting members的大多成员的支持。
  • 在Replica Set中,如果voting members的数量是5,那么一个成员成为Primary的条件是:获得超过2个voting members的支持,并且没有任何voting members 反对。只要有任意一个voting member 反对该成员成为Primary,那么该成员就不能成为Primary。

    2,强制一个成员成为Primary

    如果将一个成员的priority属性在Replica Set的所有成员中是最高的,那么该成员最有可能成为Primary。

    将成员0的priority设置5,其他成员的priority设置为1,这样,成员0成为Primary的优先级是最高的。

    cfg = rs.conf()cfg.members[0].priority = 5cfg.members[1].priority = 1cfg.members[2].priority = 1rs.reconfig(cfg)

    七,测试数据

    1,在Primary上读写数据

    db.users.insert({_id:1,name:"a",age:24})

    2,在Secondary上读取数据

    默认情况下,客户端不能从Secondary成员中读取数据。在Secondary成员上显式执行setSlaveOk之后,才能从Secondary节点读取数据。

    rs.setSalveOk()db.users.find({_id:1})

    八,查看mongod 服务器的命令行参数

    技术分享
    db.serverCmdLineOpts()
    /* 0 */{ "argv" : [ "mongod", "-f", "C:data
    s0_1.conf" ], "parsed" : { "config" : "C:data
    s0_1.conf", "net" : { "port" : 40001 }, "replication" : { "replSet" : "rs0" }, "storage" : { "dbPath" : "C:datadbdb_rs0" }, "systemLog" : { "destination" : "file", "path" : "C:datadbdb_rs0
    s0_1.log" } }, "ok" : 1}
    技术分享

    参考doc:

    Replication

    Replica Set Tutorials

    MongoDB - Replication

    Replica Set Configuration

    Force a Member to Become Primary

    MongoDB 搭建副本集

    标签:命令行参数   无法   sed   shell   监听端口   可视化   config   备份   参数   

    小编还为您整理了以下内容,可能对您也有帮助:

    如何配置MongoDB副本集

    MongoDB 已经成为市面上最知名的 NoSQL 数据库。MongoDB 是面向文档的,它的无模式设计使得它在各种各样的WEB 应用当中广受欢迎。

    MongoDB 已经成为市面上最知名的 NoSQL 数据库。MongoDB 是面向文档的,它的无模式设计使得它在各种各样的WEB 应用当中广受欢迎。最让我喜欢的特性之一是它的副本集(Replica Set),副本集将同一数据的多份拷贝放在一组 mongod 节点上,从而实现数据的冗余以及高可用性。

    这篇教程将向你介绍如何配置一个 MongoDB 副本集。

    副本集的最常见配置需要一个主节点以及多个副节点。这之后启动的复制行为会从这个主节点到其他副节点。副本集不止可以针对意外的硬件故障和停机事件对数据库提供保护,同时也因为提供了更多的节点从而提高了数据库客户端数据读取的吞吐量。

    配置环境

    这个教程里,我们会配置一个包括一个主节点以及两个副节点的副本集。

    为了达到这个目的,我们使用了3个运行在 VirtualBox 上的虚拟机。我会在这些虚拟机上安装 Ubuntu 14.04,并且安装 MongoDB 官方包。

    我会在一个虚拟机实例上配置好所需的环境,然后将它克隆到其他的虚拟机实例上。因此,选择一个名为 master 的虚拟机,执行以下安装过程。

    首先,,我们需要给 apt 增加一个 MongoDB 密钥:

    然后,将官方的 MongoDB 仓库添加到 source.list 中:

    $ sudo su

    # echo "deb "$(lsb_release -sc)"/mongodb-org/3.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.0.list

    接下来更新 apt 仓库并且安装 MongoDB。

    现在对 /etc/mongodb.conf 做一些更改

    第一行的作用是表明我们的数据库需要验证才可以使用。keyfile 配置用于 MongoDB 节点间复制行为的密钥文件。replSet 为副本集设置一个名称。

    接下来我们创建一个用于所有实例的密钥文件。

    这将会创建一个含有 MD5 字符串的密钥文件,但是由于其中包含了一些噪音,我们需要对他们清理后才能正式在 MongoDB 中使用。

    grep 命令的作用的是把将空格等我们不想要的内容过滤掉之后的 MD5 字符串打印出来。

    现在我们对密钥文件进行一些操作,让它真正可用。

    接下来,关闭此虚拟机。将其 Ubuntu 系统克隆到其他虚拟机上。

    这是克隆后的副节点1和副节点2。确认你已经将它们的MAC地址重新初始化,并且克隆整个硬盘。

    请注意,三个虚拟机示例需要在同一个网络中以便相互通讯。因此,我们需要它们弄到“互联网"上去。

    这里推荐给每个虚拟机设置一个静态 IP 地址,而不是使用 DHCP。这样它们就不至于在 DHCP 分配IP地址给他们的时候失去连接。

    像下面这样编辑每个虚拟机的 /etc/networks/interfaces 文件。

    在主节点上:

    在副节点1上:

    在副节点2上:

    由于我们没有 DNS 服务,所以需要设置设置一下 /etc/hosts 这个文件,手工将主机名称放到此文件中。

    在主节点上:

    在副节点1上:

    在副节点2上:

    使用 ping 命令检查各个节点之间的连接。

    配置副本集

    验证各个节点可以正常连通后,我们就可以新建一个管理员用户,用于之后的副本集操作。

    在主节点上,打开 /etc/mongodb.conf 文件,将 auth 和 replSet 两项注释掉。

    在一个新安装的 MongoDB 上配置任何用户或副本集之前,你需要注释掉 auth 行。默认情况下,MongoDB 并没有创建任何用户。而如果在你创建用户前启用了 auth,你就不能够做任何事情。你可以在创建一个用户后再次启用 auth。

    修改 /etc/mongodb.conf 之后,重启 mongod 进程。

    $ sudo service mongod restart

    现在连接到 MongoDB master:

    连接 MongoDB 后,新建管理员用户。

    重启 MongoDB:

    $ sudo service mongod restart

    再次连接到 MongoDB,用以下命令将 副节点1 和副节点2节点添加到我们的副本集中。

    现在副本集到手了,可以开始我们的项目了。参照 官方驱动文档 来了解如何连接到副本集。如果你想要用 Shell 来请求数据,那么你需要连接到主节点上来插入或者请求数据,副节点不行。如果你执意要尝试用副本集操作,那么以下错误信息就蹦出来招呼你了。

    如果你要从 shell 连接到整个副本集,你可以安装如下命令。在副本集中的失败切换是自动的。

    如果你使用其它驱动语言(例如,JavaScript、Ruby 等等),格式也许不同。

    希望这篇教程能对你有所帮助。你可以使用Vagrant来自动完成你的本地环境配置,并且加速你的代码。

    MongoDB 3.0 正式版发布下载

    CentOS编译安装MongoDB

    CentOS 编译安装 MongoDB与mongoDB的php扩展

    CentOS 6 使用 yum 安装MongoDB及服务器端配置

    Ubuntu 13.04下安装MongoDB2.4.3

    MongoDB入门必读(概念与实战并重)

    Ubunu 14.04下MongoDB的安装指南

    《MongoDB 权威指南》(MongoDB: The Definitive Guide)英文文字版[PDF]

    Nagios监控MongoDB分片集群服务实战

    基于CentOS 6.5操作系统搭建MongoDB服务

    MongoDB 的详细介绍:请点这里MongoDB 的下载地址:请点这里

    via: How to set up a Replica Set on MongoDB

    作者:Christopher Valerio 译者:mr-ping 校对:wxy

    本文由 LCTT 原创翻译,Linux中国 荣誉推出

    本文永久更新链接地址:

    MongoDB复制集/副本集(Replica Set)搭建

    mongo副本集/复制集是mongo高可用性特征之一,是有自动故障恢复功能的主要集群。由一个Primary节点和一个或多个Secondary节点组成。

    复制是在多台服务器之间同步数据的过程,由一组Mongod实例(进程)组成,包含一个Primary节点和多个Secondary节点

    Mongodb Driver(客户端)的所有数据都写入Primary,Secondary从Primary同步写入的数据

    通过上述方式来保持复制集内所有成员存储相同的数据集,提供数据的高可用

    Failover (故障转移,故障切换,故障恢复)

    Rendancy(数据冗余)

    避免单点,用于灾难时恢复,报表处理,提升数据可用性

    读写分离,分担读压力

    对用户透明的系统维护升级

    主节点记录所有的变更到oplog日志

    辅助节点(Secondary)复制主节点的oplog日志并且将这些日志在辅助节点进行重放(做)

    各个节点之间会定期发送心跳信息,一旦主节点宕机,则触发选举一个新的主节点,剩余的辅助节点指向新的主

    10s内各辅助节点无法感知主节点的存在,则开始触发选举

    通常1分钟内完成主辅助节点切换,10-30s内感知主节点故障,10-30s内完成选举及切换

    用户恢复数据,防止数据丢失,实现灾难恢复

    人为误操作导致数据删除,程序Bug导致数据损坏等

    首要复制节点,由选举产生,提供读写服务的节点,产生oplog日志

    备用(辅助)复制节点,Secondary可以提供读服务,增加Secondary节点可以提供复制集的读服务能力

    在故障时,备用节点可以根据设定的优先级别提升为首要节点。提升了复制集的可用性

    Arbiter节点只参与投票,不能被选为Primary,并且不从Primary同步数据

    Arbiter本身不存储数据,是非常轻量级的服务。

    当复制集成员为偶数时,最好加入一个Arbiter节点,以提升复制集可用性

    Mongodb版本3.0以上, 三台服务器均为64位

    三台服务器    --------  Primary(Centos7)、 Secondary(Centos7)、 Secondary(Debian8);架设IP分别为 192.168.1.1、1.2、 1.3

    三台服务器关闭防火墙    -------- systemctl  stop firewalld.service

    三台服务器修改mongo配置文件    --------  vi  /etc/mongod.conf 

            侦听地址除了 localhost 外再加上服务器IP; 设置复制集名字(RepliSetName)。

    开启mongod服务: mongod

    三台服务器mongo各自初始化: rs.initiate()

    Primary上副本集配置:

    rsconf(配置名称,可随意取)={_id:"副本集名",member:[{_id:0,host:"IP:port",priority:2},{_id:1,host:"IP:port",priority:1},{_id:2,host:"IP:port",priority:1}]}

    在初始化:rs.initiate(变量名,如下面的config)

    Secondary上配置:

    rs.slaveOk()    #承认自己是Secondary

    三台服务器上互相添加副本集成员:

    rs.add("IP:port"), 如在Primary上 rs.add("192.168.1.2:27017"), rs.add("192.168.1.3:27017")

    查看状态

    rs.status()

    3、rs(replication set) 常用命令:

    初始化副本集  ----  rs.initiate()

    mongo查看状态 ---- rs.status()

    初始化副本集配置

    rsconf = {_id: "rs0",

    members: [{

    _id: 0,

    host: ":27017"}]}

    rs.initiate( rsconf )

    验证副本集配置  ----  rs.config()

    增加副本集成员  ----  rs.add("Ip:port")

    移除副本集成员  ----  rs.remove("IP:port")    #此步骤在Primary上操作

    改变成员变量的优先级

    cfg = rs.conf()

    cfg.members[0].priority = 3

    cfg.members[1].priority = 1

    cfg.members[2].priority = 2

    rs.reconfig(cfg)

    配置延迟副本集

    cfg = rs.conf()

    cfg.members[0].priority = 0

    cfg.members[0].hidden = true

    cfg.members[0].slaveDelay = 3600

    rs.reconfig(cfg)

    #  07/03/2017

    mongodb单机升级为副本集

    修改配置文件,重启服务

    验证

    可以看到,修改成功

    启动第一个副本集,进入mongo27017

    副本集初始化

    结果

    验证副本集信息:

    结果

    集群之间的复制增加keyFile认证

    在172.24.32.201服务器上再启动一个27018实例,并加入副本集

    创建服务所需目录

    创建新的配置文件

    创建新的启动文件

    启动新的mongo实例

    进入27017副本集

    将刚创建的实例添加进副本集

    结果

    查看副本集状态

    结果

    验证原有数据的可用性

    我们登陆进刚加入副本集的实例,27018

    查看db,报错

    是因为secondary副本不允许读写

    临时允许命令

    发现数据一致

    开启keyfile认证就默认开启了auth认证了,为了保证后面可以登录,提前创建了用户

    登陆primary节点27017,创建管理员账号

    验证用户

    重启后进入,顺序,先关从,再关主。先启动主,再启动从

    进入主,验证账号密码

    创建读写用户

    使用新创建的用户读取数据

    至此,mongo单点已经成功升级成单节点副本集

    mongodb副本集的功能

    功能如下:
    1、数据冗余:副本集可以确保副本结点与主结点数据的更新,以防止单个数据库的服务宕机造成数据丢失的问题。
    动故障转移:副本集没有固定的主结点,整个集群会选举出一个主结点,当这个主结点不会正常工作时,会选举一个副本结点切换为主结点。

    mongodb副本集的功能

    功能如下:
    1、数据冗余:副本集可以确保副本结点与主结点数据的更新,以防止单个数据库的服务宕机造成数据丢失的问题。
    动故障转移:副本集没有固定的主结点,整个集群会选举出一个主结点,当这个主结点不会正常工作时,会选举一个副本结点切换为主结点。

    MongoDB副本集同步原理解析

    在MongoDB的副本集中,节点之间是通过oplog来同步数据。Primary节点每执行一次数据写入,都会记录一条oplog,Secondary节点会持续不断的自Primary拉取oplog并在本地回放,从而确保各节点达到数据最终一致性。

    Primary节点并发写入数据,时间点分别为t1、t2和t3,按时间先后排序为 t1 -> t2 -> t3;如果t1和t3先落库,t2后落库,那么在oplog集合中如何能保证有序呢?

    MongoDB底层通用的存储引擎为WiredTiger、In-Memory,以WiredTiger为例,MongoDB管理层调用WiredTiger引擎接口向oplog集合中插入文档(即记录);

    WiredTiger会以 oplog 的 ts 字段作为 key、文档内容作为 value,写入一条 KV 记录,wiredtiger 会保证存储(btree 或 lsm 的方式都能保证)的文档按 key 来排序,这样就解决 “Primary节点oplog如何保证有序” 的问题;

    并发写入多条oplog ts1、ts2、ts3和ts4,其中 ts1<ts2<ts3<ts4,如果ts1、ts2和ts4先写入primary成功,ts3存在延迟,还未写入,此时secondary节点自pirmary拉取oplog在本地回放,如何保证有序呢?

    MongoDB(wiredtiger 引擎)的解决方案是在读取oplog时进行,保证Secondary 节点看到一定是顺序的,具体实现机制如下:

    如此既可以确保 “secondary节点在本地回放oplog时有序”

    Secondary节点回放oplog在保证有序的前提下,如何保证高效呢?如下:

    如果OpQueue队列中的oplog有对同一个collection的操作,后续并发进行数据回放时,如何保证同一个collections中两条oplog的执行顺序呢?

    参考文档:

    MongoDB 如何保证 oplog 顺序?

    MongoDB复制集同步原理解析

    MongoDB 副本集物理备份和恢复

    MongoDB 部署在docker里,MongoDB的数据在创建docker时,通过逻辑卷进行管理和存储。当数据量过大(TB级)时,通过mongomp的逻辑备份方式,效率上已经能满足需求,所以需要提供物理备份的功能,本文主要整理MongoDB副本集通过磁盘快照的进行物理备份和恢复的方法。

    找到MongoDB副本集的hidden节点,在该节点上执行备份操作

    LVM原理及配置

    Restore a Replica Set from MongoDB Backups

    Top