blog-web/source/_posts/MongoDB/6.0、复制集.md
结发受长生 a29cff3aed 笔记迁移
2018-05-12 19:51:10 +08:00

2.7 KiB
Raw Blame History

title: 6.0、复制集 date: 2018-5-12 19:45:02 tags: - 数据库 - MongoDB - 集群 categories: - MongoDB

复制集是由一组拥有相同数据集的mongod实例所组成的集群

在这个复制集集群当中 , 各个节点可能有以下几种状态

  • Primary 主节点一个复制集至多有一个节点处于Primary状态只有主节点才对外提供读写服务。如果主节点挂掉复制集将会投票选出一个备用节点成为新的主节点。
  • Secondary 备用节点,复制集允许有多个备用节点,每个备用节点的数据与主节点的数据是完全同步的。
  • Recovering 恢复中,当复制集中某台服务器挂掉或者掉线后数据无法同步,重新恢复服务后从其他成员复制数据,这时就处于恢复过程,数据同步后,该节点又回到备用状态。
  • Arbiter 仲裁节点,该类节点可以不用单独存在,如果配置为仲裁节点,就主要负责在复本集中监控其他节点状态,投票选出主节点。该节点将不会用于存放数据。如果没有仲裁节点,那么投票工作将由所有节点共同进行。
  • Down 无效节点,当服务器挂掉或掉线时就会处于该状态。

复制集就是通过在备用节点上备份数据来提高数据库的可靠性 主节点会把所有的写操作记录到oplog当中 ( 包括所有的增删改操作 ) 备用节点通过oplog来进行数据的同步

对于mysql的集群部署 , 拥有super权限的用户可以在备用节点执行写入操作 , mongoDB的备用节点是绝对不可以进行写操作的 而且mysql的集群可以拥有双主结构

对于读操作 , 默认情况下都是指向主节点的 , 虽然备用节点也在实时更新数据 , 但数据相对主节点来说也是有可能滞后的 如果对数据的时效性要求不是特别严格 , 也可以把读操作指向备用节点 , 从而分担主节点的压力

MongoDB复制集的特点

  • 数据一致性 - 主节点在一个集群中至多有一个 , 但并不是固定的 , 但可以设定节点的优先级 , 让一个性能更好的节点优先成为主节点
  • 大多数原则 ( 二分之一原则 ) - 集群存活节点小于等于二分之一的时候 , 集群不可写 , 只可读 也就是说 , 能否选举出新的主节点 , 是由当前复制集成员的存活数量来决定的 即使之前的主节点正常工作 , 备用节点挂掉的过多 , 这个主节点也会自动降级为备用节点
  • 备用节点无法写入 - 在备用节点写入数据有造成主键冲突的可能性
  • 自动容灾 - 主节点挂掉以后 , 会自动从备用节点中选举出一个主节点