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文件的配置
这一步是整个流程最关键的，要注意各个节点的配置不要出现杂乱。配置实例如下：

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

复制代码

其他两个节点只需要按照规划好的资源更换一下端口、日记位置、数据位置即可。
3、启动各个mongodb节点
使用上一步规划好的配置文件启动对应实例，

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

1. mongosh.exe --port 37027

复制代码

初始化集群：

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

复制代码

备注：
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目次下的文件
这个没有现实操纵，一开始查到的方案都是这种，但是教程说的都是二进制文件，当时没反应过来，什么二进制，二进制什么，在哪里，怎么拿到这个新的二进制文件。以是就没有使用这个方案。大概也是需要下载新的安装包，然后部分更换。具体方案可以自行查找其他教程。
   之前更新其他软件的时候，也接纳了更换部分更换的方式，但是因为偷懒以及不太清楚应该都要更换哪些文件，少更换了一部分以是导致更新完之后影响使用，且没有找到解决方式，只是临时不使用那部分功能，以是对于这类方式个人目前照旧比较审慎。如果接纳这样的方式一定要特殊注意。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

继续阅读请点击广告