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