mongodb高可用部署有主从复制和复制集

MongoDB 高可用可用分两种:
Master-Slave 主从复制：
只需要在某一个服务启动时加上–master 参数，而另一个服务加上–slave 与–source 参数，

即可实现同步。MongoDB 的最新版本已不再推荐此方案。主从复制虽然可以承受一定的负载压力，但这种方式仍然是一个单点，如果主库挂了，数据写入就成了风险。

Replica Sets复制集：
MongoDB 在 1.6 版本对开发了新功能replica set，这比之前的replication 功能要强大一
些，增加了故障自动切换和自动修复成员节点，各个DB 之间数据完全一致，大大降低了维
护成功。auto shard 已经明确说明不支持replication paris，建议使用replica set，replica set

故障切换完全自动。

要构建一个 MongoDB Sharding Cluster，需要三种角色：
Shard Server
即存储实际数据的分片，每个Shard 可以是一个mongod 实例，也可以是一组mongod 实例
构成的Replica Set。为了实现每个Shard 内部的auto-failover，MongoDB 官方建议每个Shard
为一组Replica Set。
Config Server
为了将一个特定的collection 存储在多个shard 中，需要为该collection 指定一个shard key，
例如{age: 1} ，shard key 可以决定该条记录属于哪个chunk。Config Servers 就是用来存储：
所有shard 节点的配置信息、每个chunk 的shard key 范围、chunk 在各shard 的分布情况、
该集群中所有DB 和collection 的sharding 配置信息。
Route Process
这是一个前端路由，客户端由此接入，然后询问Config Servers 需要到哪个Shard 上查询或
保存记录，再连接相应的Shard 进行操作，最后将结果返回给客户端。客户端只需要将原本
发给mongod 的查询或更新请求原封不动地发给Routing Process，而不必关心所操作的记录
存储在哪个Shard 上。

关于复制集配置架构官网给了建议：(https://docs.mongodb.com/manual/core/replica-set-members/)

The minimum recommended configuration for a replica set is: A primary, a secondary, and an arbiter. Most deployments, however, will keep three members that store data: A primary and two secondary members.

大意是：最少配置复制集是一个主，一个从，一个仲裁节点。但是比较多的部署方案是部署是一个主和两个从节点。所以说是可以没有仲裁节点的。