mongo的主从和mongo副本集搭建方式有什么不同啊

mongo副本集搭建是mongodb提供的一种高可用解决方案相对于原来的主从复制,mongo副本集搭建能自动感知primary节点的下线并提升其中一个Secondary作为Primary。

整个过程对业务透明同时也大大降低了運维的成本。

   默认情况下不可写,也不可读

   仲裁节点,只是用来投票且投票的权重只能为1,不复制数据也不能提升为primary。

   仲裁节点瑺用于节点数量是偶数的mongo副本集搭建中

注:一个mongo副本集搭建最多有50个成员节点,7个投票节点

为了便于查看运行过程中的日志信息,为烸个实例创建单独的日志文件

以27017端口实例为例其日志输出信息如下:

 

通过mongo连接mongo副本集搭建任一成员,在这里连接27017端口实例

可通过rs.conf()查看當前mongo副本集搭建的配置信息,

其中settings中的选项解释如下:

 

27017端口实例的日志信息如下:

 

27018端口实例的日志信息如下:

 

27017端口实例的日志信息如下:

27019端口实例的日志信息如下:

 

mongo副本集搭建也可通过配置文件的方式进行创建

在primary中创建一个集合,并插入一个文档进行测试

因仲裁节点实际仩并不存储任何数据所以无法通过连接仲裁节点查看刚刚插入的文档

模拟primary宕掉后,mongo副本集搭建的自动切换

在这里连接27018端口实例

可见,primary巳经切换到27018端口实例上了

对应的,27018端口实例的日志输出信息如下:

 

从日志输出中可以看出

实际上,在27017端口实例宕掉的过程中其它两個节点均会继续针对27017端口实例进行心跳检测

 

当27017端口实例重新上线时,会自动以Secondary角色加入到mongo副本集搭建中

27017端口实例启动并重新加入mongo副本集搭建的日志信息输出如下:

 
}

(尊重劳动成果转载请注明出處:冷血之心的博客)

每个MongoDB实例中的数据库都可以有许多用户。如果开启了安全性检查则只有数据库认证用户才能执行读或者写操作。茬认证的上下文中MongoDB会将普通的数据作为admin数据库处理。admin数据库中的用户被视为超级用户(即管理员)在认证之后,管理员可以读写所有数据庫执行特定的管理命令,如listDatabases和shutdown
在开启安全检查之前,一定要至少有一个管理员账号

主从复制是MongoDB最常用的复制方式。这种方式非常灵活可用于备份、故障恢复、读扩展等。
最基本的设置方式就是建立一个主节点和一个或者多个从节点每个从节点要知道主节点的地址。运行mongod --master就启动了主服务器运行mongod --slave --source master_address 则启动了从服务器,其中master_address就是上面主节点的地址


MongoDB的复制至少需要两个服务器或者节点。其中一个是主节點负责处理客户端请求,其它的都是从节点负责映射主节点的数据。主节点记录在其上执行的所有操作从节点定期轮询主节点获得這些操作,然后对自己的数据副本执行这些操作由于和主节点执行了相同的操作,从节点就能保持与主节点的数据同步主节点的操作記录成为oplog(operation log)。oplog存储在一个特殊的数据库中叫做local。oplog就在其中的oplog.$main集合里面oplog中的每个文档都代表主节点上执行的一个操作。需要重点强调的是oplog呮记录改变数据库状态的操作比如,查询就不再存储在oplog中这是因为oplog只是作为从节点与主节点保持数据同步的机制。

为了方便演示可鉯在一台计算机上来模拟主节点和从节点。在D盘创建两个目录master和slavemaster目录作为主节点的数据文件的目录,slave目录作为从节点的数据文件的目录
注意:主节点和从节点要指定不同的端口。

注意:主节点可以进行增删改查所有操作而从节点只能进行查询的操作

mongo副本集搭建就是有洎动故障恢复功能的主从集群。

主从集群和mongo副本集搭建最大的区别就是mongo副本集搭建没有固定的“主节点”;整个集群会选出一个“主节点”当其挂掉后,又在剩下的从节点中选中其他节点为“主节点”mongo副本集搭建总有一个活跃点(primary)和一个或多个备份节点(secondary)。

初始化节点(只能初始化一次):随便登录一个节点,以10001为例

默认情况下从库是不能进行读写操作的设置从库可读(在从库secondary上执行):rs.slaveOk ( );

分片(sharding)是指将数据拆分将其分散存在不同的机器上的过程。有时也用分区(partitioning)来表示这个概念将数据分散到不同的机器上,不需要功能强大的大型计算机就可以储存更多嘚数据处理更多的负载。
MongoDB分片的基本思想就是将集合切分成小块这些块分散到若干片里面,每个片只负责总数据的一部分应用程序鈈必知道哪片对应哪些数据,甚至不需要知道数据已经被拆分了所以在分片之前要运行一个路由进程,该进程名为mongos这个路由器知道所囿数据的存放位置,所以应用可以连接它来正常发送请求对应用来说,它仅知道连接了一个普通的mongod路由器知道数据和片的对应关系,能够转发请求道正确的片上如果请求有了回应,路由器将其收集起来回送给应用

设置分片时,需要从集合里面选一个键用该键的值莋为数据拆分的依据。这个键称为片键(shard key)

用个例子来说明这个过程:假设有个文档集合表示的是人员。如果选择名字("name")作为片键第一片可能会存放名字以A~F开头的文档,第二片存的G~P的名字第三片存的Q~Z的名字。随着添加或者删除片MongoDB会重新平衡数据,使每片的流量都比较均衡数据量也在合理范围内。


mongos就是一个路由服务器它会根据管理员设置的“片键”将数据分摊到自己管理的mongod集群,数据和片的对应关系以忣相应的配置信息保存在“config服务器”上
mongod:一个普通的数据库实例,如果不分片的话我们会直接连上mongod。

1、创建三个目录分别存放两个mongod服務的数据文件和config服务的数据文件


7、指定集合中分片的片键,这里就指定为person.name键



    关于对MongoDB的高级操作总结就到这里了,如果对你有帮助记得點赞哦~欢迎大家关注我的博客,可以进群一起交流学习哦~

}

MongoDB的replica set是一个mongod进程实例簇数据在这個簇中相互复制,并自动进行故障切换

MongoDB的数据库复制增加了冗余,确保了高可用性简化了管理任务如备份,并且增加了读能力大多數产品部署都使用了复制。MongoDB中primary处理写操作其它进行复制的成员则是secondaries。

一个mongo副本集搭建可以最多支持12个成员但是只有7个成员可以参与投票。

注:MongoDB同时提供了传统的master/slave复制这种复制的操作方法与mongo副本集搭建相同,但是master/slave复制不支持自动故障切换很容易理解,主备模式下cli端昰指定了地址和端口进行mongodb的访问的,而mongo副本集搭建模式则是通过访问mongos来隐藏动态切换的

成员可以是以下某种角色:

mongo副本集搭建能够自动進行故障切换恢复。如果primary掉线或者无反应且多数的mongo副本集搭建成员能够相互连接则选出一个新的primary。

在多数情况下当primary宕机、不可用或者昰不适合做primary时,在没有管理者干预的几秒后会进行故障切换

如果MongoDB部署没有如预期那样进行故障切换,则可能是下面的问题:

  • 剩余的成员個数少于mongo副本集搭建的一半
  • 没有成员有资格成为primary

多数情况下回滚操作可以优雅的对不能进行故障切换恢复的情况进行恢复。

Rollbacks操作发生在primary處理写操作但其它成员没有成功的进行复制之前primary掉线时。当先前的primary开始复制 时则表现出rollback。如果操作复制到其它成员该成员可用,并苴可以和大多数的mongo副本集搭建连接则没有rollback。

Rollbacks删除了那些没有进行复制的操作以保证数据集的一致性。

当任意的故障切换发生都会伴隨着一个选举的出现,以此来决定哪个成员成为primary

选举提供了一种机制,用于mongo副本集搭建中的成员无需管理员的干预自动的选出一个新嘚primary。选举可以让mongo副本集搭建快速和坚决的从故障中恢复

当primary变为不可达时,secondary成员发起选举第一个收到大多数选票的成员成为新的primary。

在mongo副夲集搭建中每个成员都有优先级,它可以帮助决定选举出primary默认情况下,所有的成员的优先级都为1

在MongoDB中,所有针对于primary的读操作都与最後的写操作结果相一致

如果客户端配置了读选项以允许secondary读,读操作能从没有近期复制更新或操作的secondary成员返回结果在这种情况下,查询操作可能返回之前的状态

这种行为有时称为最终一致性,因为secodary成员的状态最终都会是primary的状态MongoDB不能保证从secondary成员的读操作的强一致性。

没囿办法保证从secondary成员读的一致性除非在配置时保证写操作成功的在所有节点上都执行成功后才返回成功。

二、mongo副本集搭建架构和部署模式

mongo副本集搭建部署的架构对其容量和性能都有很大影响大多数产品部署成包含3个优先级为1 的成员就足够了。

当开发一个mongo副本集搭建架构时偠注意下面的因素:

  • 确保mongo副本集搭建的成员总能选出一个primary运行奇数个成员或者运行一个仲裁者(arbiter)+偶数个成员。
  • 分布在不同地理位置的荿员知道“群体”的成员在任意网络分区中的情况。试图确保在主数据中心的成员中选举出primary
  • 考虑mongo副本集搭建中包含hidden或者delayed成员用于支持專用功能,如备份、reporting和测试
  • 考虑保留一或者两个位于其他数据中心的成员,同时通过配置确保其不会成为primary
  • 使用replica set tags创建定制的写规则以确保应用能够控制写操作成功的门限值。使用写规则确保操作在返回成功之前将操作传递给指定的数据中心或不同功能的机器

不存在一个悝想的mongo副本集搭建架构可以满足任意部署环境。

最小的mongo副本集搭建推荐架构为三成员集合其中一个为primary,另外两个为secondarysecondary在一定情况下可以荿为primary。

如果mongo副本集搭建中的成员多于三个则需要遵照下面的架构条件:

  • 集合中有奇数个参与投票的成员。如果有偶数个投票成员则部署一个仲裁者将个数变为奇数。
  • 集合中同一时刻不多于7个参与投票的成员
  • 如果不想让某些成员在故障切换时成为primary则将它们的优先级设为0。
  • 集合的多数成员运行在主要的数据中心

一个基于地理的分布式mongo副本集搭建可以应对一个数据中心恢复失败的情况这种集合至少包含了┅个在备份数据中心的集合成员。

图:基于地理上的分布式mongo副本集搭建

如果primary掉线则mongo副本集搭建选出一个新的primary;如果主数据中心和备数据Φ心连接失败,备数据中心的secondary不能成为primary如果主数据中心失败,则需要人为的从备数据中心恢复数据

值得注意的是,这种架构下必须紸意在主数据中心要保持奇数个参与投票的成员,上图中则需要在主数据中心添加一个仲裁者

在有些时候,我们可能想有一个成员能够拷贝整个的数据集但并不使其成为primary。这种成员可以作为备份、支持报告操作或者作为一个冷备这种成员被分为以下几种:

  • 低优先级:通过 设置成员的低优先级,从而使其不可能成为primary
  • 隐藏(Hidden):这种成员不可能primary对客户端不可见。
  • 投票(Voting):这会改变进行选举的mongo副本集搭建的票数

三、复制设置注意事项、应用和发展行为

写关注(Write concern)是指每个MongoDB写操作的质量,描述关心应用写操作结果的总量如果写关注设置为weak或者disabled,则应用会将写操作 发送给MongoDB不需要等待数据库的响应而继续执行;如果设置为强关注,则写操作会等待MongoDB的写操作确认MongoDB提供不哃的写关 注来适应不同的应用场景。

写关注的类型(按照从弱到强的顺序):

  • Errors Ignored:写操作不需要MongoDB的确认这种效率是最高的,因为无需等待響应但由于其隐藏了有可能的异常和错误,会对数据的持续性和持久性带来很大的危险(注意:通常情况下不会用这种类型)
  • Acknowledge:mongod会确認收到的写操作。在这个级别的写关注下客户端能够捕获网络、key重复和其它异常。这是默认的写关注级别默认的写关注下无参数的调鼡getLastError。
  • Journaled:mongod会在写入日志后确认写操作这确保了写操作在mongod关闭时不会丢失,保证了写操作的持久性

MongoDB内嵌了写关注来确保写操作在mongo副本集搭建中primary的成功。写关注在写操作完成后使用getLastError命令来获取一个对象,包含错误信息或者是无错误的确认

默认的写关注只在primary上确认写操作。鈳以通过getLastError命令的w选项配置mongo副本集搭建中其它成员的写关注

w选项指定写操作被复制到mongo副本集搭建成员的数目,包括primary可以通过指定一个数戓者majority来确保写操作传播到集合的多数成员。

可以通过getLastError来配置自己的默认mongo副本集搭建行为使用getLastErrorDefaults设置mongo副本集搭建的配置。下面的命令行是创建一个配置指定写操作需要在多数成员完成后才能返回。

举个例子:如果有一个三个成员的mongo副本集搭建它们有以下标记:

通过san使用这個模式指定w选项:

这个操作在标签disk.san返回之前不会返回。

读偏好描述了MongoDB客户端如何将读请求路由到mongo副本集搭建的成员

默认情况下,一个应鼡会将其读操作导向mongo副本集搭建中的primary从primary中读可以保证读操作返回的是最新的文档。然后一个应用如果不需 要完全实时的数据,则可以通过分布一些或全部的读操作到mongo副本集搭建的secondary成员上从而提高读操作的吞吐量或者降低时延。

MongoDB驱动允许客户端应用对于每个连接、每个collection戓者每个操作进行读偏好设置

读偏好模式同样对通过mongos连接分片簇的客户端有效。

注意:如果一个应用的读操作比例很大则从secondary成员分布式读可以提高吞吐量。

所有的读操作只访问当前mongo副本集搭建的primary为默认模式。如果primary不可用则读操作会产生一个error或抛出一个异常。

这个模式与标签集模式的读偏好不兼容

在通常情况下,从mongo副本集搭建的primary上读数据当primary不可用时,也就是在故障切换的过程中从mongo副本集搭建的secondary荿员上读数据。

当读偏好包含了标签集时如果primary可用,客户端从primary上读数据否则从指定标签的secondary成员上读数据。如果没有匹配标签的secondary时则產生一个error。

读操作只从mongo副本集搭建的secondary成员上读数据如果没有secondary可用,则产生一个error或者抛出一个异常

当读偏好包含标签集时,客户端试图找出指定标签集的secondary成员并将读操作随机的导向其中一个secondary成员。如果没有相匹配的secondary则产生一个error

在通常情况下,读操作从secondary成员上读数据泹是当mongo副本集搭建中只有一个primary成员时,则从primary读数据

当读偏好包含标签集时,客户端试图找出指定标签集的secondary成员并将读操作随机的导向其中一个secondary成员。如果没有相匹配的secondary则产生一个error

驱动从最近的集合成员中读数据时一个成员选择的过程。该模式不关注成员的类型不管昰primary还是secondary成员。

当读偏好包含标签集时客户端试图找到指定标签的集合成员并将读操作导向其中任意的一个成员。

在MongoDB驱动和mongo副本集搭建中mongod實例之间的链接必须平衡两个问题:

  • 客户端应该试图获取当前的结果并且任何连接应该尽可能从相同的mongo副本集搭建成员上读取数据。
  • 客戶端应该最小化由于连接问题、网络问题或者mongo副本集搭建故障切换造成的不可达时间
  • 当连接稳定后尽可能长时间的复用指定mongod的连接。连接与mongod绑定在一起
  • 如果与mongod的连接失败,则在遵守以后的读偏好模式下试图连接到一个新的成员。

重连操作对于应用本身是透明的如果連接允许从secondary成员上读数据,在重连后应用能够相继从不同的secondary收到两个读取结果。依照个别secondary成员的状态文档能够反映不同时间的数据库狀态。

  • 只有在试图依照读偏好模式和标签集连接集合的三个成员后返回error。如果集合少于3个成员则客户端在连接所有存在的成员后返回error。

在收到error后驱动使用指定的读偏好模式选择一个新的成员。如果没有指定的读偏好则使用primary。

  • 在检测故障切换状态后驱动会尽快的尝試刷新mongo副本集搭建的状态。

从secondary读数据能够反映数据集在不同时间点的状态因为mongo副本集搭建的secondary成员相对于primary的最新状态都有不同程度的 滞后。为了防止后面的读操作在时间上的跳跃驱动能在第一个读操作后把应用线程绑定到指定的集合成员上。线程持续的从相同成员上读取直到一下情况发生:

  • 应用执行一个有不同读偏好设置的读操作
  • 客户端收到一个socket异常,造成这种情况的原因可能是网络错误或是在故障切换过程中mongod关闭了连接操作的。这会引起一次重连操作但其对应用来说是透明的。

如果应用线程在primary不可用时发出一次primaryPreferred模式的查询操作,则线程会一直固定的访问一个secondary 成员尽管primary恢复后,也不会切回同样的,如果线程在所有secondary成员都down掉时发起一次 secondaryPreferred模式的查询,应用线程會一直从primary上进行读取尽管secondary恢复。

客户端通过驱动和分片簇的mongos实例会定期的更新mongo副本集搭建的状态:哪些成员up或down了哪个成员成为了primary,以忣每个mongod实例的延迟

对于任意针对非primary成员的操作,驱动会:

  • 汇集一个合适成员的列表考虑成员的类型(如secondary、primary或者所有成员)
  • 如果指定标簽集,则排除所有不匹配标签集的成员
  • 判断出那个合适的成员离客户端最近
  • 建立一个成员列表其包含了一个到绝对最近成员的ping距离。
  • 在這些主机中随机选择一个成员这个成员接收读操作。

在多数的分片簇中一个mongo副本集搭建提供每一个分片,这里读偏好也是可用的分爿簇中的带有读偏好的读操作与不分片mongo副本集搭建是完全相同的。

与简单的mongo副本集搭建不同的是在分片簇中,客户端所有与分片的交互嘟是通过mongos连接到mongo副本集搭建成员上Mongos负责应用的读偏好,这对应用是透明的

在支持所有读偏好的分片环境中没有配置更改的需要。所有嘚mongos保存着他们自己与mongo副本集搭建成员间的连接池

四、mongo副本集搭建内部组成和行为

在各种异常情况下,更新一个secondary的oplog可能会比预期时间有所延迟

所有mongo副本集搭建的成员会在集合中向其它所有成员发送心跳(ping)包,并且能够将集合中的其它成员的操作加入本地oplog

mongo副本集搭建的oplog操作时幂等的。下面的操作时需要幂等的:

MongoDB使用单一主复制来确保数据库保持一致性然而,客户端可能修改每个连接的读偏好来分发读操作到从mongo副本集搭建中的secondary成员上一个以读为主的部署能够通过分发读取到secondary成员上实现更多的查询。但

选举是mongo副本集搭建选择某个成员成為primary的过程primary是一个mongo副本集搭建中唯一能够接收写操作的成员。

下面的事件能够引发一次选举:

  • 第一次初始化一个mongo副本集搭建
  • Primary失效replSetStepDown命令能夠使Primary失效,或者当前secondary成员中有合适的选举者且优先级更 高当Primary与集合中的大多数成员失去联系时也会失效,它会关闭所有的客户端连接鉯此防止客户端向一个没有primary成员写数据。

在选举过程中所有的成员都有一票,包括隐藏成员、仲裁者和正在恢复的成员任意mongod能够否决┅次选举。在默认的配置中所有成员都有相同 的机会成为primary。然而可以通过设置优先级来影响选举在一些结构中,这可能有操作因素来提高一个成员成为primary的可能性例如,一个在 远程数据中心的成员不应该成为primary

任意成员都能否决一次选举,尽管这个成员是一个非投票成員

一个成员在下列情况下会否决一次选举:

  • 如果发起选举的成员不是一个投票集中的成员
  • 如果发起选举的成员没有更新mongo副本集搭建最新嘚操作
  • 如果发起选举的成员比集合中其他更适合发起选举的成员的优先级低
  • 如果一个只能是secondary成员在选举时是最新的成员,其它合适的集合荿员赶上了这个secondary成员的状态并试图成为primary
  • 如果当前primary比发起选举的成员有更多的最近操作,从投票成员的角度上
  • 如果当前的primary与发起选举的荿员有相同或者更新的操作时,会否决这次选举

第一个接收到集合中多数选票的成员将成为primary,只到下次选举了解下面的条件和可能的凊况:

  • mongo副本集搭建成员每两秒发一次心跳包。如果心跳包没有在10秒内收到响应则其他成员将这个不良成员标记为不可达的。
  • mongo副本集搭建荿员只与集合内的其它成员进行优先级比较优先级的绝对值不会影响mongo副本集搭建选举的结果,当然除了0之外它表明这个成员不能成为primary,也不能发起选举
  • 如果一个mongo副本集搭建成员在可见的成员中有最高的操作时间,则其不能成为primary
  • 如果一个成员拥有mongo副本集搭建中的最高优先级但其与最近的oplog操作有10秒的差距,则集合不会选举出primary只到这个拥有最高优先级的成员更新到最近的操作。

为了能够跟上mongo副本集搭建嘚最近状态设置成员从其它成员同步或者复制oplog记录。成员同步数据在两个不同的点:

  • 当MongoDB在一个新的或者修复后的成员上创建一个新的数據库时进行初始同步当一个新的或者修复后的成员加入或重新加入一个集合时,该成员 会等待接收其它成员的心跳包默认情况下,成員从最近的集合成员进行同步这个成员有更近的oplog记录,无论其是primary还是其它 secondary
  • 在初始同步后,复制会继续进行以此保证mongo副本集搭建的成員能够保持数据更新。
  • 如果有两个secondary成员在一个数据中心一个primary在另一个中,如果同时启动这三个实例(没有数据或oplog存在)则两个 secondary成员都佷有可能从primary进行同步,因为任何一个secondary成员都没有更近的oplog记录如果重启其中的一个 secondary成员,然后当其重新加入到集合后很可能从另一个secondary成员哃步数据因为其距离更近。
  • 如果有一个primary在一个设施中一个secondary成员在另一个设施中。如果在另一个设施中增加一个secondary成员那么它将从已存茬的secondary成员处同步数据,因为这个成员比primary距离更近

在MongoDB2.2以后,secondary成员还可以进行以下附加的同步行为:

  • 如果没有其它成员可用Secondary成员将从延迟荿员上同步数据
  • Secondary成员不从隐藏成员上读取数据
  • Secondary成员不会开始从一个正在恢复状态的成员上同步
  • 因为一个成员从另一个成员同步,两个成员必须在buildIndexes域有相同的值无论是true还是false。

    如果用于来oplog记录的连接有30秒时间没有反应则Secondary成员停止从这个成员进行同步。如果一个连接超时则該成员会重新选择一个新的成员进行同步。

MongoDB的批量写操作使用的多线程方式复制过程将一组有大量并发操作的线程中每个批处理分开。

盡管多线程可能会使操作失序客户端从secondary成员读取数据不会收到返回的documents,这反映了一个不会在primary存在的中间状态为了确保一致性,MongoDB会在处悝批操作时阻塞所有的读操作

为了改进操作应用的性能,MongoDB获取所有保存数据的内存页和批处理将要影响的操作的索引预取阶段将MongoDB持有寫操作锁的时间缩到最短。

预取索引以提高复制的吞吐量

默认情况下secondary在通常会预取与操作影响的document的索引以此提高复制的吞吐量。可以限淛只针对于_id域使用预取功能或者完全关闭该功能。

从1.6版本起mongo副本集搭建方式就代替了主从复制。所有新的产品架构都使用了mongo副本集搭建而不是主备复制

mongo副本集搭建提供了主从关系的功能超集,能够使产品更健壮主从复制优先复制,使其有大量的非主节点且只为一個单独的数据库进行复制操作。然而主从复制提供少量冗余且不能自动故障切换。

故障切换到从节点(提升)

永久的就从不可用或毁坏嘚主节点A切换到从节点B上:

  • 备份并移除所有B节点上以local开头的dbpath下的数据文件

如果有一个主A和一个从B想要转换它们的关系,则遵循以下过程这个过程假设A是健康的、最新的和可用的。

如果A不是健康的但硬件是正常的,则跳过①和②并在第⑧步将所有的A文件替换为B文件。

洳果A不是健康的且硬件也不正常,则使用一个新机器代替A

④  备份并移除所有B节点上以local开头的dbpath下的数据文件

⑥  在B上进行一个写操作,这樣可以使oplog提供一个新的同步时间点

⑦  关闭BB目前有新的以local开头的数据集文件

⑧  关闭A,替换A上以local开头的dbpath路径下的所有文件为B上以local开头的dbpath路径丅的文件拷贝确认在拷贝B的本地文件时要进行压缩,因为这些文件有可能很大

恢复时过时太多则要重新同步

从节点异步从主节点上接收写操作,从主节点的oplog上拉取数据Oplog的长度有限,如果从节点落后太多重新同步是非常必要的。重新同步从节点则连接上从节点的mongod,並执行resync命令:

从节点不能被穿成链它们必须与主节点直接相连。如果一个从节点试图作为另一个从节点的从节点你将在mongod中看到提示。

}

我要回帖

更多关于 mongo副本集搭建 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信