mongodb集群之副本集

1. 适用场景

备份

1）服务器磁盘余量不足以备份时
虽然mongo的mongodump也可以备份，但这种备份的过程是先备份出备份文件，然后在需要的时候使用文件进行恢复。这种方式的优点是移植性较高，备份文件可以随便复制到任何地方。不太好的情况是，这个备份文件最开始一定是先在执行备份命令的服务器上（一定在这里吗还是也可以远程备份呢），此时如果数据很大而服务器的磁盘容量不足以支持或者在备份之后剩余很少的时候，这种方式可能就有问题，所以可以考虑借助副本集冗余存储的特点进行远程备份。
2）想要备份到其他服务器
不想先备份再还原，而是直接备份到其他服务器上的。在这种业务场景下，我们只是借助副本集达成备份的功能，所以一般要在备份完之后把对应的节点剔除，如果原来使用单例模式启动mongo还需要恢复成单例的模式，避免影响原来的业务。

高可用性

一般，在千万量级以下应用中，正式环境大多会采用副本集来配置，提高数据服务的容错能力，也就是避免单点故障致使整个项目停服。采用副本集的情况下，主节点发生故障时能够切换，所以对外就跟没有故障一样。

相关文章：https://developer.aliyun.com/article/1532081
说明：上面是工作中遇到的场景，还有其他场景。

2. 集群搭建

如何搭建

资源规划

1）要用几个节点
一主一从
一主一从一冲裁
一主多从（2个从节点以上）

备注：一般推荐使用奇数个节点（其实不太理解，因为原来是奇数个，停掉一个之后不是也会变成偶数个吗，那么一开始是偶数应该也不会影响啊），防止无法选举出主节点的情况；如果全停，重新启动的话，一般先启动主节点，再启动从节点

遇到过的情况：只配置了2个节点时，第一次从主节点备份的时候因磁盘空间不足，导致从节点处于STARTUP状态，再次启动时没注意启动顺序，导致原来的主节点也处于STARTUP 状态，无法使用。

2）服务器资源规划
这个部分要提前规划好，不仅能一定程度避免出错，也是运维中重要的信息。主要考虑服务器，端口，相关文件位置（一般会需要数据、日志、配置、pid等文件，数据和配置是必须的，其他的根据自己的需求）。

• 服务器：如果是临时备份用可以根据实际情况选择，如果是业务用，一般选择一个服务器一个节点，而不是同一台服务器且服务器最好在不同地理区域，避免区域性故障导致全部出问题。

• 端口：一般使用默认端口27017，但有的时候为了安全或者端口已经被占用的情况，就需要根据实际需求和情况另选

• 数据文件：一般不要跟直接放在软件安装位置内，防止别人在不知道的情况下变更软件影响到数据（特别时是直接删除的时候影响很大）

根据资源完成各节点conf文件的配置

关键配置：端口、日志、数据、副本集名

启动各个mongodb节点

这一步还没有形成副本集，所以启动的顺序任意，在以后的启动建议都先启动主节点再启动从节点。

初始化集群信息

这一步指定了集群中的mongo实例信息、集群名、各实例的优先级，也可以根据需要添加其他配置。集群与非集群其实主要在于这一步，如果没进行初始化（配置文件不配置集群名），那么就是非集群式的mongo

搭建实例

Linux搭建实例（待定）

Windows搭建实例

1、资源规划
1）节点规划：一主二从
2）服务器资源规划

对应物理文件位置如下：

这些要提前创建好，这里可以根据自己的习惯分，可以把每个节点的信息单独放在一个路径下，也可以按照功能放，比如配置文件单独放一个文件夹，日志文件单独放一个文件夹，数据当然是每个节点单独放。
2、根据资源完成各节点conf文件的配置
这一步是整个流程最关键的，要注意各个节点的配置不要出现混乱。配置实例如下：

#mongodb端口
port=37027#绑定ip，只有这个ip才可以访问上mongodb;0.0.0.0表示所有的都可以访问，如果要做安全管控可以限制ip
bind_ip=0.0.0.0# 日志文件的路径
logpath=D:\mysoftware\MongoDB\zone\ser1\log\mongodb37027.log# 数据文件的目录
dbpath=D:\mysoftware\MongoDB\zone\ser1\data0-1#日志以追加的方式存在
logappend=true# fork=true linux以后台方式启动，在window上没有用# 此参数较大比较好，单位是 MB,默认是磁盘可用空间的 5%
oplogSize=1024# 复制集的名称，同一个复制集的名称必须要相同
replSet=myreplace1

其他两个节点只需要按照规划好的资源替换一下端口、日志位置、数据位置即可。

3、启动各个mongodb节点
使用上一步规划好的配置文件启动对应实例，

4、初始化集群
进入某个（任意一个都可以）实例：

mongosh.exe --port 37027

初始化集群：

rs.initiate({_id : "myreplace1",members : [{_id : 0,host : "localhost:37027","priority":10},{_id : 1,host : "localhost:37028"},{_id : 2,host : "localhost:37029"}]
});

备注：
1）myreplace1为副本集名称，要跟conf文件的replSet保持一致，host为对应实例的IP + 端口
2）priority表示成位主节点的优先级，这里相当于让37027对应的实例优先成位主节点

3. 副本集基础操作

• rs.status()：查看集群状态
• rs.hello()：副本集成员信息和当前节点的状态
• rs.conf()：查看集群配置，比如优先级什么的
• rs.secondaryOk() / rs.slaveOk ()：临时开启从节点可执行相关命令(不同版本可能使用的不同)

更多操作见官方文档： https://mongodb.net.cn/manual/reference/method/js-replication/

4.集群平滑升级

方案一 从头安装一套新版本并使用原来配置文件启动对应节点
方案前置条件:

• 数据单独存放
• 配置文件最好单独存放
  升级操作：
• 采用压缩包安装方式，就只需要下载新版本然后解压就行，这就相当于中间件升级成功了
• 使用新版本mongo + 原来conf文件一起启动即可
  升级顺序：
  先从后主。因为主节点很关键，所以我们先升级从节点，也就是在从节点服务器上先停掉服务然后用mongo + 原来conf文件一起启动即可。主节点的升级稍微复杂一点，需要先将为从节点，然后再按照从节点的方式升级。

一般地，不要同时把主从都升级完，先升级从节点观察一小段时间没问题再升级主节点。

优点：操作简单，风险小（除非要删除旧版本，且数据正好放在这个路径内）。

缺点：

• 这个就相当于从头安装一遍，所以会同时存在多个版本的安装文件（其他的虽然停用），所以如果担心不同的人可能使用不同的版本，可以把原来的删掉，但是如果此时数据放在这里但是又漏看就容易出问题，这也是前面建议把数据单独分开放的原因。
• 不会自动添加服务路径，所以要么手动添加，要么每次启动切换路径或使用绝对路径

方案二 替换bin目录下的文件
这个没有实际操作，一开始查到的方案都是这种，但是教程说的都是二进制文件，当时没反应过来，什么二进制，二进制什么，在哪里，怎么拿到这个新的二进制文件。所以就没有使用这个方案。大概也是需要下载新的安装包，然后部分替换。具体方案可以自行查找其他教程。

之前更新其他软件的时候，也采用了替换部分替换的方式，但是因为偷懒以及不太清楚应该都要替换哪些文件，少替换了一部分所以导致更新完之后影响使用，且没有找到解决方式，只是暂时不使用那部分功能，所以对于这类方式个人目前还是比较谨慎。如果采用这样的方式一定要特别注意。