MongoDB的基础

1mongodb有哪些高可用架构

第一种:PSSPrimary + Secondary + Secondary模式,通过Primary和Secondary搭建的Replica Set

该模式下 Replica Set节点数必须为奇数,目的是选主投票的时候要出现大多数才能进行选主决策。

 MongoDB的基础

 

 

 

 

第二种:PSAPrimary + Secondary + Arbiter模式,使用Arbiter搭建Replica Set

偶数个数据节点,加一个Arbiter构成的Replica Set

 MongoDB的基础

2、如何配置mongodb副本集

 

config_repl={_id:‘repl‘,members:[                 #副本名称与配置文件中要一致
                        {_id:1,host:‘18.2.11.113:27017‘,priority:10},
                        {_id:2,host:‘18.2.11.123:27017‘,priority:1},
                        {_id:3,host:‘18.2.11.123:27018‘,arbiterOnly:true}]}   #如果设置仲裁机添加参数
 rs.initiate(config_repl)           #初始化副本集
 rs.status()         

3mongodb副本集有哪些角色

普通角色

1)主节点【primary

接收所有的写请求,然后把修改同步到所有Secondary。一个Replica Set只能有一个Primary节点,当Primary挂掉后,其他Secondary或者Arbiter节点会重新选举出来一个主节点。
默认读请求也是发到Primary节点处理的,可以通过修改客户端连接配置以支持读取Secondary节点。

2)副本节点【secondary

与主节点保持同样的数据集。当主节点挂掉的时候,参与选主。

3)仲裁者【arbiter

不保有数据,不参与选主,只进行选主投票。使用Arbiter可以减轻数据存储的硬件需求,Arbiter几乎没什么大的硬件资源需求,但重要的一点是,在生产环境下它和其他数据节点不要部署在同一台机器上。

 

特殊角色

1)Arbiter

Arbiter 节点只参与投票,不能被选为 Primary,并且不从 Primary 同步数据。
当节点宕机导致复制集无法选出 Primary时,可以给复制集添加一个 Arbiter 节点,即使有节点宕机,仍能选出 Primary。
Arbiter 本身不存储数据,是非常轻量级的服务,当复制集成员为偶数时,最好加入一个 Arbiter 节点,以提升复制集可用性。

2)Priority0

Priority0节点的选举优先级为0,不会被选举为 Primary。
比如你跨机房 A、B 部署了一个复制集,并且想指定 Primary 必须在 A 机房,这时可以将 B 机房的复制集成员 Priority 设置为0,这样 Primary 就一定会是 A 机房的成员。
(注意:如果这样部署,最好将大多数节点部署在 A 机房,否则网络分区时可能无法选出 Primary。)

3)Vote0

Mongodb 3.0里,复制集成员最多50个,参与 Primary 选举投票的成员最多7个,其他成员(Vote0)的 vote 属性必须设置为0,即不参与投票。

4)Hidden

Hidden 节点不能被选为主(Priority 为0),并且对 Driver 不可见。
Hidden 节点不会接受 Driver 的请求,可使用 Hidden 节点做一些数据备份、离线计算的任务,不会影响复制集的服务。

5)Delayed

Delayed 节点必须是 Hidden 节点,并且其数据落后与 Primary 一段时间(可配置,比如1个小时)。
Delayed 节点的数据比 Primary 落后一段时间,当错误或者无效的数据写入 Primary 时,可通过 Delayed 节点的数据来恢复到之前的时间点。

 

4当副本集中master宕机,后会发生什么?当master重启后会发生什么?"选举机制

复制集通过 replSetInitiate 命令或 rs.initiate() 命令进行初始化。
初始化后各个成员间开始发送心跳消息,并发起 Primary 选举操作,获得大多数成员投票支持的节点,会成为 Primary,其余节点成为 Secondary。

 1)故障转移的前提:

从库不能连接到主库(默认超过10s,可通过heartbeatTimeoutSecs参数控制),由从库发起选举,主库放弃primary 角色,比如执行rs.stepdown 命令

Mongodb副本集通过心跳检测实现自动failover机制,进而实现高可用的。

 

大多数
假设复制集内投票成员(后续介绍)数量为 N,则大多数为 N/2 + 1,当复制集内存活成员数量不足大多数时,整个复制集将无法选举出 Primary,复制集将无法提供写服务,处于只读状态。
关于大多数的计算如下表所示

投票成员数

大多数

容忍失效数

1

1

0

2

2

0

3

2

1

4

3

1

5

3

2

 

Primary 的选举受节点间心跳、优先级、最新的 oplog 时间等多种因素影响

 

 MongoDB的基础

 

 

2)影响选举的因素和条件

1)心跳Heartbeats

副本集成员每两秒向彼此发送心跳(ping)。如果心跳未在 10 秒内返回,则其他成员将拖欠的成员标记为不可访问。

 

2)会员优先Member Priority

在副本集拥有稳定的主节点后,选举算法将“尽最大努力”尝试让具有最高 priority可用值的次节点进行选举。成员优先权影响选举的时间和结果;具有较高优先级的中学选举比具有较低优先级的中学相对更早地进行选举,而且更有可能获胜。但是,即使有更高优先级的次要实例可用,也可以在短时间内将优先级较低的实例选为主要实例。副本集成员继续调用选举,直到可用的最高优先级成员成为主要成员。

权重值

一个影响最终选举结果的重要因子,但个人认为,优先最高的成员不一定会被选举为primary,只是在成员其他条件相同的情况下起到决定作用,对数据库而言,单纯靠优先级来决定new primary有点太野蛮,得考虑数据的一致性及维护一致性的复杂度和成本。多说一句,优先级为0的成员(当然包含延迟复制成员、hidden成员)肯定不会成为new primary。官方文档如是说,只要现primary的优先级最高,或者没有优先级更高的并能在10秒内追赶上最新oplog的从库,选举是是不会被触发的。可以换句话理解,当前成员相互间优先级的比较结果变化是会触发选举的,都能触发选举了,也就有可能对选举结果产生一定影响。

3)镜像读取Mirrored Reads

4)丢失数据中心Loss of a Data Center

5)网络分区Network Partition

简单讲就是三点:

(1)能够与多数节点建立连接
(2))具有较新的 oplog
(3)具有较高的优先级(如果有配置)
 
 
 

MongoDB的基础

上一篇:spark连接mysql数据库


下一篇:解决var/run/mysqld没有pid和sock文件