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

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

关于MongoDB

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

而目前接手过来的项目所用的就是,所以也就主要了解了这个模式。

截图1

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

主节点[Primary]

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

副本节点[Secondary]

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

仲裁者[Arbiter]

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

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

搭建集群

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

前期准备

首先准备三台测试机：

然后就是mongo的安装包(由于线上用的是3.4.2的版本，所以保持统一)

安装mongo

这里统一安装在下。

首先解压并重命名：

然后在下新建几个文件：

这里需要注意下，配置文件中配置的文件路径一定要存在，不然在启动mongo时会出错，mongo启动时也不会自动生成。

接着分配创建配置文件：

主节点：

备份节点：

仲裁点:

在使用上只是最基本的配置，实际场景中可以根据自己的业务需求进行配置，其他参数供参考：

节点配置完之后就可以启动mongo了，cd到bin目录下：

截图2配置节点

最后，就需要配置主、备、仲裁节点了。首先我们选择一台服务器进行连接：

截图3

然后进行配置：

如果不出意外，配置正常生效，基本也就完成了，可以通过命令查看相关信息。

到这里，你可以登录数据库测试下成果了，看下正常的数据库操作，主从是否同步了。测试的话这里就不再多说了

数据备份与还原

简单搭建完集群之后，需要将原来的测试环境数据迁移过来，所以涉及到了mongo的备份与还原。

相对来说还是比较容易的，通过和来实现：

总结

到这里，对于mongo有了一定了解和认识，也基本掌握了搭建和迁移流程，面对（无开发，无文档，无注释）的老项目也有点底气了，剩下的时光就要在边看代码边吐槽的日子中渡过啦，想象就心累…