MongoDB高可用

对于MongoDB，可以支持使用单机模式提供服务，但是在实际的生产环境中，单机模式将面临很大的风险，一旦这个数据库服务出现问题，就会导致线上的服务出现错误甚至崩溃。因此，在实际生产环境下，需要对MongoDB做相应的主备处理，提高数据库服务的可用性。

对于提高可用性，一些博文里提到了使用主从模式（master-slaver）。

WARNING:
Deprecated since version 3.2: MongoDB 3.2 deprecates the use of master-slave replication for components of sharded clusters.

主从模式是高可用的一种方案。然而从上面这段警告中可以知道，在高版本的MongoDB（3.2以上）中，官方已经不推荐使用主从模式，取而代之的，是使用复制集（Replica Set）的方式做主备处理。

IMPORTANT:
Replica sets replace master-slave replication for most use cases. If possible, use replica sets rather than master-slave replication for all new production deployments. This documentation remains to support legacy deployments and for archival purposes only.

一、主从复制

对于主从复制的原理，非常简单，简单的说就是几台机器之间进行同步操作，我们在主节点上操作数据，需要同步到其他子节点上。下面我们来实战一下。
首先创建一个cluster文件夹，然后在该文件夹中创建两个子文件夹master和slave分别存放主从节点的数据文件。

二、副本集

副本集具有自动故障恢复的功能。
主从集群和副本集最大的区别就是副本集没有固定的“主节点”；整个集群会选出一个“主节点”，当其挂掉后，又在剩下的从节点中选中其他节点为“主节点”，副本集总有一个活跃点(primary)和一个或多个备份节点(secondary)。

在复制集中，有且只有一个主节点(primary)，可以包含一个或多个从节点(secondary)，主从节点直接会通过心跳检测来确定节点是否健康或存活。所有的读写操作都是在主节点上进行的，如果要实现读写分离，需要进行相应的处理，这个最后会说。从节点会根据oplog（也就是操作日志）来复制主节点的数据。

image.png

MongoDB复制集
除了主从节点外，MongoDB的复制集中还存在着一种叫仲裁者(Arbiter)的角色。一个仲裁者节点是比较轻量级的，因为它不会去复制主库的数据，因此也就不会成为主节点；但是，它的作用是在投票选举阶段——当主节点故障时，仲裁者可以进行投票。一般来说，不建议一个复制集中包含超过一个仲裁者。
当主节点突然故障后，MongoDB有自己的机制，会自动切换，通过选举，在从节点中选出一个节点作为新的主节点。

image.png

三、分片

分片(sharding)是指将数据拆分，将其分散存在不同的机器上的过程。有时也用分区(partitioning)来表示这个概念。将数据分散到不同的机器上，不需要功能强大的大型计算机就可以储存更多的数据，处理更多的负载。

MongoDB分片的基本思想就是将集合切分成小块。这些块分散到若干片里面，每个片只负责总数据的一部分。应用程序不必知道哪片对应哪些数据，甚至不需要知道数据已经被拆分了，所以在分片之前要运行一个路由进程，该进程名为mongos。这个路由器知道所有数据的存放位置，所以应用可以连接它来正常发送请求。对应用来说，它仅知道连接了一个普通的mongod。路由器知道数据和片的对应关系，能够转发请求道正确的片上。如果请求有了回应，路由器将其收集起来回送给应用。

设置分片时，需要从集合里面选一个键，用该键的值作为数据拆分的依据。这个键称为片键(shard key)。

用个例子来说明这个过程：假设有个文档集合表示的是people。如果选择名字(“name”)作为片键，第一片可能会存放名字以A-F开头的文档，第二片存的G-P的名字，第三片存的Q~Z的名字。随着添加或者删除片，MongoDB会重新平衡数据，使每片的流量都比较均衡，数据量也在合理范围内。

• 分片的架构图如下，这里用两台服务器来进行分片操作：

  
  
  image.png

• 下图展示了在MongoDB中使用分片集群结构分布：

  
  
  image.png