MongoDB 第5章 MongoDB高级查询(mongodb数据库)
541
2022-05-29
在学习复制的概念之前,首先接着前面一章节的还有点未完结的内容做个简单的介绍,主要是自动故障转移、异步复制、以及附加功能,这些在此只做简单的介绍,在以后的相关章节中会专门深入学习。
1、自动故障转移
当Primary服务和架构中其他成员中断通信超过10秒,Replica Set将尝试选举其他成员成为一个新的Primary服务,获得多票数的Scondary将成为Primary。
架构如下:
说明:
在一个Replica Set架构中,如果Primary不可达,则会在除Primary之外的其他成员中自动选举一个Scondary来作为新的Primary,使Replica Set保证可用,起到自动故障转移的目的。
2、异步复制
Secondaries从Primary异步应用所有的操作,正在异步应用Primary操作时,集合可能继续工作,但是此时并不会复制数据到其他成员,所以当客户端通过Secondary节点返回数据时可能不是数据集得最新数据。
3、附加功能
Replica Set提供了大量的选项,以便支持应用的需要。比如你可以部署一个多数据中心的Replica Set,或者通过调整成员的优先级去控制选举结果,Replica Set可以支持成员的报表、容灾恢复,或者备份功能。
4、复制概念(本章重点)
该章节主要描述和提供了关于Replica Set的操作、配置、和行为的实例,关于Replica Set的简介,以及文档的管理命令请学习前面相关章节。
4.1、Replica Set Memebers(成员)
MongoDB一个Replica Set是一组mongod进程,提供了冗余和高可用特性,一个Replica Set的成员包括如下:
Primary:primary接收所有的写操作
Secondary:从primary复制所有的操作来持有一份相同的数据集,Secondary也许添加一些特殊用途的配置,比如,Secondary没有选举权和优先级设置为0等。
当然也可以添加一个arbiter(仲裁者)在一个Replica Set架构中,Arbiter不能持有一份复制的数据,然后仲裁者在Replica Set架构中扮演一个控制选举的角色,当Replica Set中primary不可达,需要重新选举其他成员作为新的primary时。
一个Replica Set最多可以有12个成员,然后在同一时间中只有7个成员能够被投票选举。
一个Replica Set最小的架构包括:1个primary、1个secondary、1个arbiter,然后大多数的部署将保持三个成员来存储数据:一个primary和两个secodary成员。
4.2、Primary
在前面的章节已经了解过了primary基础知识,在此章节深入学习,在一个Replica Set架构中,当且仅有一个primary服务用于接收所有的写操作,MongoDB在primary应用写操作了,同时记录primary写操作的主日志(oplog),Secondary成员复制这个日志同时根据该复制日志进行复制数据集合的操作。
如下为一个三个成员的Replica Set架构:
说明:
Replica Set所有成员都可以接收读操作,默认情况下,从primary进行读操作,可以通过配置来更改读操作行为。
默认情况下,客户端直接通过primary进行读操作,以此来保证返回的是一个文档最新的版本,然而通过分配一些读操作给secondary成员,以此来改善系统的读吞吐量或者减少当一个应用不需要完整的数据时不可预知的问题。
注意:当指定一个primary之外的成员能接收读操作时,你必须格外的小心,因为secondary成员可能并没有从primary同步最新的数据集合。
原理结构如下:
如果选择一个没有primary的读模式,也许应用获取不到实时的数据,因为secondary会有一些耽搁,MongoDB驱动提供了五种读模式:
* primary:默认模式,所有的读操作来自当前Replica Set架构的primary。
* primaryPreferrd:大多数情况下,读操作通过primary,但是当primary不可达时,读操作通过secondary进行
* secondary:所有读操作通过secondary成员进行。
* secondaryPreferred:该模式下,读操作通过secondary进行,但是当secondary不可达时,读操作会自动通过primary进行。
* nearset:读操作通过replica set架构中网络延误最近的成员进行,不管该成员是什么类型。
Replica Set有且仅有一个primary成员。如果当前primary成员不可达,会自动选择一个其他成员作为新的primary,来保证整个架构的可用。
4.3、Secondaries
在前面已经介绍过secondary,它主要通过primary日志来进行数据的复制操作,有一些延迟,如果一个应用直接通过secondary来读取数据,可能获取的不是Replica Set架构最新的数据,一个Replica Set架构中可以有一个或者多个secondary成员,如下是三个成员的Replica Set架构,包括两个secondary成员:
尽管客户端不能直接通过Secondary进行写操作,客户端能通过secondary进行数据读取操作,一个secondary也可以在primary不可达的情况下转换成primary,同时也可以自主制定一些配置来赋予secondary特殊功能:
如阻止一个secondary成员在选举中成为primary,此时只需将该成员的优先级(priority)设置为0即可。
(1)、Replica Set成员优先级0介绍
一个优先级(priority)为0的secondary成员不可能在primary不可达时转变为新的primary,优先级为0的成员不能触发选举事件,但是它可以持有一份复制的数据集合,也可以进行读操作和选举,配置一个成员的优先级为0,主要是为了阻止该成员成为primary,在多数据中心部署中这是非常有用的。
如下一个三个成员的Replica Set架构中,在第一个数据中心的主机上,一个primary成员和一个secondary成员,在的第二个数据中心的主机上一个优先级为0的secondary不可能成为primary。
(2)、优先级为0成员的作用
一个优先级为0的成员通常作为一个数据备份,在一些Replica Set架构中,也许不可能在一个合适的时间添加一个新的成员,一个持有当前数据备份的一个备用成员可以替代一些不可用的成员。
在许多的案例中,你不需要通过设置优先级为0去将成员作为备份成员,在不同的硬件以及地理分布式部署中,优先级0的备用确保仅有符合条件的成员才能成为primary。
如果在架构中已经有7个成员有投票选举权时,将其他的成员配置为非选投票成员时,可以通过该方法实现。
(3)、优先级为0成员和故障转移
通过配置一个优先级为0成员,考虑潜在的故障模式,包括所有可能的网络分区,始终确保你的主要数据中心包含符合规则的选举成员和确定成员。
(4)、配置
注意:rs.resconfig()方法可以使当前的primary服务下台,当一个primary下台(不可达)之后,mongod会关闭所有的客户端连接,这个过程将花费10到20秒。为了成功的配置replica set,大多数成员必须是可访问的,如果你的replica set成员是偶数,可以添加一个arbiter来确保获取多数选票的成员成为primary。
(1)、检索当前replica set配置
rs.conf()费那个发返回一个replica set包含当前replica set配置的文档。
一个mongo客户端连接到一个primary,运行rs.conf()方法同时分配给一个变量,如下:
cfg = rs.conf()
该方法会返回一个Replica Set架构包含所有成员配置的文档。
(2)、分配优先级值为0
为了分配一个优先级值给Replica Set中的一个成员,访问该成员的配置文档实用一个数组索引,在下面的例子中改变数组角标为2的成员的优先级为0
cfg.members[2].priority = 0
该配置只有当重新配置replica set之后才能生效。
(3)、重新配置replica set
使用rs.reconfig()方法重新配置replica set用于更新配置文档。
在rs.reconfig()方法中使用cfg变量即可。
rs.reconfig(cfg)
如阻止一个应用通过secondary进行读操作,此时只需要将该成员在Replica Set架构中隐藏即可。
隐藏Replica set成员
(1)、一个隐藏的成员仍然保持一份主要的数据集合,但是客户端应用程序对其不可见,一个隐藏成员必须总优先级始终为0,不可能变为primary,且使用db.isMaster()方法不能显示隐藏成员,如下是一个五个成员的replica set架构,四个成员都持有primary的数据集合,但是有一个成员是隐藏成员。
(2)、读操作
客户端不会通过一个隐藏成员来进行读操作,因此这些成员不能接受其他成员基础复制操作,使用隐藏成员任务有如报表、备份,延迟的成员应该被隐藏。
在一个分片集群中,mongos路由不能和隐藏成员进行交互。
(3)、选举
如果你停止一个隐藏成员,以此来确保集合有更多活跃的成员或者primary停止。
由于备份的目的,可以避免停止隐藏成员使用db.fsyncLock()和db.fsyncUnlock()非那操作去刷新所有的写操作在备份操作中对mongod实例进行枷锁。
如通过运行一个历史快照来从一个确认的错误中恢复,如无意中删除数据库。
MongoDB 边缘数据中心管理 EDCM
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。