Replica Set 是 mongod 的实例集合,包含三类节点角色:
Primary( 主节点 )
Secondary( 副本节点 )
Arbiter( 仲裁者 )
Primary( 主节点 ):
只有主节点可读可写,Primary 接收所有写请求,然后把数据同步到所有 Secondary 。一个 Replica Set 只有一个 Primary 节点,当 Primary 挂掉后,其他 Secondary 或者 Arbiter 节点会选举一个 Primary 节点,这样就又可以提供服务了。读请求默认是发到 Primary 节点处理,如果需要故意转发到 Secondary 需要客户端修改一下配置。
Secondary( 副本节点 ):
数据副本节点,当主节点挂掉的时候,参与选主。
Arbiter( 仲裁者 )
不存数据,不会被选为主,只进行选主投票。使用 Arbiter 可以减轻在减少数据的冗余备份,又能提供高可用的能力。
数据多副本,在故障的时候,可以使用完的副本恢复服务(自动恢复)。
读写分离,读的请求分流到副本上,减轻主(Primary)的读压力;
节点直接互有心跳,可以感知集群的整体状态;
每两个节点之间互有心跳,这种模式会导致节点的心跳几何倍数增大,单个 Replica Set 集群规模不能太大,一般来讲最大不要超过 50 个节点。
备注:参与投票节点数要是奇数,这个非常重要。因为偶数会导致脑裂,也就是投票数对等的情况,无法选出 Primary。
Sharding 模式
Replica Set 模式无法应对海量数据所以有了分布式技术。有了Sharding 模式。
解决性能和容量瓶颈一般来说优化有两个方向:
纵向优化
横向优化
纵向优化是传统企业最常见的思路,持续不断的加大单个磁盘和机器的容量和性能。
横向优化通俗来讲就是加节点。业务上要划分系统数据集,并在多台服务器上处理,做到容量和能力跟机器数量成正比。
那么,实际情况下,哪一种更具可行性呢?
自然是分布式技术的方案,纵向优化的方案非常容易到达物理极限,横向优化则对个体要求不高,而是群体发挥效果。MongoDB 的 Sharding 模式就是 MongoDB 横向扩容的一个架构实现。
创建不同的data、log
不同的ip或者端口号启动
配置文件要加上
replication:
#复制:
#副本集的名称
replSetName: myrs
根据配置文件启动
->进入主节点:
初始化:
rs.initiate()
添加副本节点:
rs.add("副本节点ip")
添加仲裁节点:
rs.addArb("仲裁节点ip")
rs.add("仲裁节点ip",false)
状态
rs.status
->进入副本节点:
确认是副本节点:
rs.slave()
rs.slave(true)
取消是副本节点:
rs.slave(false)