接手老项目的痛——MongoDB学习及集群搭建

近一些变动，有一个老项目交由我们组负责维护，碰到这样的事情我的内心是崩溃的，但还得强颜欢笑，拍着胸脯说没问题。更悲哀的是，该项目中还使用了mongo，还是自己搭建的，没有交由DBA统一管理，无奈，只能赶鸭子上架，自己学习mongo了。

关于MongoDB

mongodb的集群搭建方式主要有三种，主从模式，Replica set模式，sharding模式, 三种模式各有优劣，适用于不同的场合，属Replica set应用为广泛，主从模式现在用的较少，sharding模式为完备，但配置维护较为复杂。

而目前接手过来的项目所用的就是Replica set,所以也就主要了解了这个模式。官网介绍可以点击这里

其中Replica Set模式中三类角色有必要知道下：

主节点[Primary]

接收所有的写请求，然后把修改同步到所有Secondary。一个Replica Set只能有一个Primary节点，当Primary挂掉后，其他Secondary或者Arbiter节点会重新选举出来一个主节点。默认读请求也是发到Primary节点处理的，需要转发到Secondary需要客户端修改一下连接配置。

副本节点[Secondary]

与主节点保持同样的数据集。当主节点挂掉的时候，参与选主。

仲裁者[Arbiter]

不保有数据，不参与选主，只进行选主投票。使用Arbiter可以减轻数据存储的硬件需求，Arbiter跑起来几乎没什么大的硬件资源需求，但重要的一点是，在生产环境下它和其他数据节点不要部署在同一台机器上。

注意，一个自动failover的Replica Set节点数必须为奇数，目的是选主投票的时候要有一个大多数才能进行选主决策。

搭建集群

了解了基本概念之后，就开始尝试搭建集群，为了更好的理解，特意找了三台测试机进行部署。

前期准备

首先准备三台测试机：

10.100.1.101 主节点(master)
 10.100.1.102 备节点(slave)
 10.100.1.103 仲裁点(arbiter)