26 - 高可用 - Replica Set - 副本集模式 - P、S、A

Replica Set 副本集模式

Replica Set 是 mongod 的实例集合，包含三类节点角色：
Primary（ 主节点 ）
Secondary（ 副本节点 ）
Arbiter（ 仲裁者 ）

Primary（ 主节点 ）：
只有主节点可读可写，Primary 接收所有写请求，然后把数据同步到所有 Secondary 。一个 Replica Set 只有一个 Primary 节点，当 Primary 挂掉后，其他 Secondary 或者 Arbiter 节点会选举一个 Primary 节点，这样就又可以提供服务了。读请求默认是发到 Primary 节点处理，如果需要故意转发到 Secondary 需要客户端修改一下配置。
Secondary（ 副本节点 ）：
数据副本节点，当主节点挂掉的时候，参与选主。
Arbiter（ 仲裁者 ）
不存数据，不会被选为主，只进行选主投票。使用 Arbiter 可以减轻在减少数据的冗余备份，又能提供高可用的能力。

MongoDB 的 Replica Set 副本集模式特点：

数据多副本，在故障的时候，可以使用完的副本恢复服务（自动恢复）。
读写分离，读的请求分流到副本上，减轻主（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)