39 lines
2.7 KiB
Markdown
39 lines
2.7 KiB
Markdown
---
|
||
title: 6.0、复制集
|
||
date: 2018-2-11 19:45:02
|
||
tags:
|
||
- 数据库
|
||
- MongoDB
|
||
- 集群
|
||
categories:
|
||
- MongoDB
|
||
---
|
||
|
||
复制集是由一组拥有相同数据集的mongod实例所组成的`集群`
|
||
<!-- more -->
|
||
在这个复制集集群当中 , 各个节点可能有以下几种状态
|
||
+ `Primary` 主节点，一个复制集至多有一个节点处于Primary状态，只有主节点才对外提供读写服务。如果主节点挂掉，复制集将会投票选出一个备用节点成为新的主节点。
|
||
+ `Secondary` 备用节点，复制集允许有多个备用节点，每个备用节点的数据与主节点的数据是完全同步的。
|
||
+ `Recovering` 恢复中，当复制集中某台服务器挂掉或者掉线后数据无法同步，重新恢复服务后从其他成员复制数据，这时就处于恢复过程，数据同步后，该节点又回到备用状态。
|
||
+ `Arbiter` 仲裁节点，该类节点可以不用单独存在，如果配置为仲裁节点，就主要负责在复本集中监控其他节点状态，投票选出主节点。该节点将不会用于存放数据。如果没有仲裁节点，那么投票工作将由所有节点共同进行。
|
||
+ `Down` 无效节点，当服务器挂掉或掉线时就会处于该状态。
|
||
|
||
复制集就是通过在备用节点上备份数据来提高数据库的可靠性
|
||
主节点会把所有的**写操作**记录到`oplog`当中
|
||
( 包括所有的增删改操作 )
|
||
备用节点通过oplog来进行数据的同步
|
||
|
||
> 对于mysql的集群部署 , 拥有super权限的用户可以在备用节点执行写入操作 , mongoDB的备用节点是绝对不可以进行写操作的
|
||
> 而且mysql的集群可以拥有双主结构
|
||
|
||
对于**读操作** , 默认情况下都是指向主节点的 , 虽然备用节点也在实时更新数据 , 但数据相对主节点来说也是有可能滞后的
|
||
如果对数据的时效性要求不是特别严格 , 也可以把读操作指向备用节点 , 从而分担主节点的压力
|
||
|
||
MongoDB复制集的特点
|
||
+ **数据一致性** - 主节点在一个集群中至多有一个 , 但并不是固定的 , 但可以设定节点的优先级 , 让一个性能更好的节点优先成为主节点
|
||
+ **大多数原则 ( 二分之一原则 )** - 集群存活节点小于等于二分之一的时候 , 集群不可写 , 只可读
|
||
也就是说 , 能否选举出新的主节点 , 是由当前复制集成员的存活数量来决定的
|
||
即使之前的主节点正常工作 , 备用节点挂掉的过多 , 这个主节点也会自动降级为备用节点
|
||
+ **备用节点无法写入** - 在备用节点写入数据有造成主键冲突的可能性
|
||
+ **自动容灾** - 主节点挂掉以后 , 会自动从备用节点中选举出一个主节点
|