从这一篇开始，我们要踏上MongoDB进阶之路啦，想想还有点小开心呢。一筐猪镇楼。
引入复制集
我们先来想一个场景，如果本地项目使用MongoDB，都是下载，安装，连接一条龙服务。这实际也就是单点模式，那如果我们项目要上线了，这个时候还是一个数据库，就可能出问题。比如我们写了个淘宝（嘘，假装是个大牛），双十一那天晚上，数据库挂了，emmm，这秒秒钟损失多少钱啊，不敢想象，这个时候，可能你就拜拜啦。所以我们要把这种可能性扼杀到摇篮里面，这就有了复制集的用武之地。
了解复制集
复制集也就是多个数据库，一个挂了，其他的还能顶上，而不至于系统挂。具体的逻辑图如下：
复制集里面节点主要包括三类，上面已经知道啦有两种，分别是主节点和从节点，还有一个是投票节点。
他们各自的作用：
主节点：写操作。
从节点：复制主节点的数据，提供读操作。
投票节点：在主节点出现故障的时候，系统会在从节点中自动投票选举新的主节点。这个投票节点就是在这个投票选举情况下使用的。
复制集的特征
1.主节点唯一不固定
我们从上面的图上就可以看出来这个特征，也就是当主节点没有啥问题的时候，从节点不会成为主节点，且也不会有新的主节点，这说明了唯一性。当主节点出现问题了，从节点中的一个会成为主节点，这说明了不固定性。
2.大多数原则
当前复制集中，存货节点的数量必须大于节点总数的1/2，这样才能触发选举。如果小于1/2，则将复制集中的主节点自动降为从节点，也就是复制集不提供写功能。这是为什么，等我学习了再说，先放着哈。
3.从库无法写入
这边从节点是不能写入的，MongoDB有严格的控制。
