产品中心
前言
最近一些变动，有一个老项目交由我们组负责维护，碰到这样的事情我的内心是崩溃的，但还得强颜欢笑，拍着胸脯说没问题。更悲哀的是，该项目中还使用了mongo，还是自己搭建的，没有交由DBA统一管理，无奈，只能赶鸭子上架，自己学习mongo了。
为什么使用集群架构？
主从：故障转移:无法实现,如果主机宕机，需要关闭slave并且按照master模式启动。无法解决单点故障 无法autofailover 不可以自动主从的切换
为了解决主从的问题，MongoDB3.0之后出现副本集，副本集解决了故障转移的问题，但是一个副本集中的数据是相同的，无法做到海量数据的存储。所以就需要一个架构去解决这个问题。也就是分片式集群。
一个健壮的简单的MongoDB集群的搭建需要十个服务进程（分开搭建需要十台服务器），这里在一台虚拟机上进行搭建。
关于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)
然后就是mongo的安装包(由于线上用的是3.4.2的版本，所以保持统一)
配置节点
最后，就需要配置主、备、仲裁节点了。首先我们选择一台服务器进行连接：
然后进行配置：
数据备份与还原简单搭建完集群之后，需要将原来的测试环境数据迁移过来，所以涉及到了mongo的备份与还原。
相对来说还是比较容易的，通过mongodump和mongorestore来实现：
./bin/mongodump -h 10.100.1.101 -d testdb -o .# mongodump -h dbhost -d dbname -o dbdirectory# -h:MongDB所在服务器地址，例如：127.0.0.1，当然也可以指定端口号：127.0.0.1:27017# -d:需要备份的数据库实例，例如：test# -o：备份的数据存放位置./bin/mongorestore -h 10.100.1.102 -d testdb testdb# mongorestore -h <hostname><:port> -d dbname <path># --host <:port>, -h <:port>：MongoDB所在服务器地址，默认为： localhost:27017# --db , -d ：需要恢复的数据库实例# --drop：恢复的时候，先删除当前数据，然后恢复备份的数据# <path>：mongorestore 最后的一个参数，设置备份数据所在位置# --dir：指定备份的目录,你不能同时指定 <path> 和 --dir 选项。
到这里，对于mongo有了一定了解和认识，也基本掌握了搭建和迁移流程，面对三无（无开发，无文档，无注释）的老项目也有点底气了，剩下的时光就要在边看代码边吐槽的日子中渡过啦，想象就心累…
好了，以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对的支持。
