接手老项目的痛——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有了一定了解和认识,也基本掌握了搭建和迁移流程,面对(无开发,无文档,无注释)的老项目也有点底气了,剩下的时光就要在边看代码边吐槽的日子中渡过啦,想象就心累…

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180821A0A1L500?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券