轻松掌握组件启动之MongoDB(上):高可用复制集架构环境搭建 ...

打印 上一主题 下一主题

主题 502|帖子 502|积分 1506

MongoDB复制集

复制集架构

在生产环境中,强烈不建议使用单机版的MongoDB服务器。原因如下:
单机版的MongoDB无法保证系统的可靠性。一旦进程发生故障或是服务器宕机,业务将直接不可用。此外,一旦服务器上的磁盘损坏,数据会直接丢失,而此时并没有任何副本可用。
为了确保数据的高可用性和冗余性,我们建议使用Mongodb复制集(Replication Set)。复制集由一组Mongod实例(进程)组成,其中包含一个Primary节点和多个Secondary节点。所有的数据写入操作都会被写入Primary节点,并且Secondary节点会从Primary节点同步写入的数据,以保持复制集内所有成员存储相同的数据集。这样可以提供数据的高可用性。复制集的功能依赖于两个方面:

  • 数据写入时将数据迅速复制到另一个独立节点上,确保数据的冗余性和可用性。
  • 在接受写入的节点发生故障时,系统能够自动选举出一个新的替代节点,以确保系统的连续性和可用性。

在实现高可用性的同时,Mongodb复制集还具有其他几个附加作用:
数据分发:复制集可以将数据从一个区域复制到另一个区域,从而减少另一个区域的读取延迟。
读写分离:复制集还支持读写分离的功能。通过将不同类型的压力分别在不同的节点上执行,可以有效地分担系统的负载。
异地容灾:复制集还可以实现异地容灾。在数据中心发生故障时,可以快速切换到异地部署的节点。
早期版本的MongoDB使用了一种Master-Slave的架构,该做法在MongoDB 3.4版本之后已经废弃。因为Master-Slave 其中Master 宕机后不能自动恢复,只能靠人为操作,可靠性也差,操作不当就存在丢数据的风险。
三节点复制集模式

常见的复制集架构通常由3个成员节点组成,其中存在几种不同的模式,具体取决于配置和需求。
PSS模式(官方推荐模式)

在常见的复制集架构中,PSS(Primary+Secondary+Secondary)模式是一种常见的配置,它由一个主节点和两个备节点组成。

在这种模式下,如果主节点不可用,复制集会智能地选择其中一个备节点作为新的主节点,并继续正常的操作。这种自动切换的机制确保了系统的连续性和可用性,同时减少了数据丢失的风险。旧的主节点在可用时重新加入复制集。

PSA模式

PSA(Primary+Secondary+Arbiter)模式是一种常见的架构配置。它由一个主节点、一个备节点和一个仲裁者节点组成。

在这种PSA模式下,Arbiter节点的主要作用是作为一个仲裁者来参与选举投票。它不存储数据副本,也不提供实际的业务读写操作。因此,即使Arbiter节点发生故障,也不会对业务产生直接影响,只会影响选举投票过程。主节点负责处理所有的业务读写操作,并且有一个完整的数据副本。备节点也存储了一个完整的数据副本,并在主节点故障时承担主节点的角色。而Arbiter节点则参与选举投票,帮助复制集在主节点发生故障时选择一个新的主节点。

典型三节点复制集环境搭建

即使只有一台服务器,以单节点模式启动复制集也是一个值得考虑的选择。

  • 单机多实例启动复制集
  • 单节点启动复制集
复制集注意事项

关于硬件:

  • 由于正常的复制集节点都有可能成为主节点,它们的地位是相等的。因此,为了确保系统的稳定性,必须确保各节点的硬件配置保持一致。
  • 为了避免多个节点同时宕机,每个节点使用的硬件必须具有独立性。这样可以保证即使一个节点宕机,其他节点仍然可以正常工作,确保系统的连续性和可靠性。
关于软件:

  • 在复制集中,每个节点的软件版本必须保持一致,这样可以避免出现无法预料的问题。
  • 值得注意的是,增加节点并不会提高系统的写入性能。
环境准备:

  • 安装 MongoDB并正确配置好环境变量
  • 确保你的计算机硬盘上有充足的空间,至少需要10GB或更多的可用空间。
准备配置文件

为了实现复制集的最佳性能和可靠性,建议将复制集的每个mongod进程部署在不同的服务器上。目前我们在一台机器上运行3个进程,因此需要对它们进行以下配置:

  • 配置不同的端口:(28017/28018/28019)
  • 配置不同的数据目录:
  1. mkdir ‐p /data/db1
  2. mkdir ‐p /data/db2
  3. mkdir ‐p /data/db3
复制代码

  • 配置不同的日志文件路径:(例如:/data/db1/mongod.log)
创建配置文件 /data/db1/mongod.conf 时,你可以进行以下设置:
  1. # /data/db1/mongod.conf
  2. systemLog:
  3.   destination: file
  4.   path: /data/db1/mongod.log
  5.   logAppend: true
  6. storage:
  7.   dbPath: /data/db1
  8. net:
  9.   bindIp: 0.0.0.0
  10.   port: 28017
  11. replication:
  12.   replSetName: rs0
  13. processManagement:
  14.   fork: true
复制代码
我们可以按照以上步骤修改端口和路径,分别配置 db2 和 db3。请确保配置文件使用 YAML 格式。
启动 MongoDB 进程
  1. mongod ‐f /data/db1/mongod.conf
  2. mongod ‐f /data/db2/mongod.conf
  3. mongod ‐f /data/db3/mongod.conf
复制代码
注意:如果启用了 SELinux,可能阻止上述进程启动。简单起见请关闭 SELinux。
  1. # 永久关闭,将SELINUX=enforcing改为SELINUX=disabled,设置后需要重启才能生效
  2. vim /etc/selinux/config
  3. # 查看SELINUX
  4. /usr/sbin/sestatus ‐v
复制代码
总结

在本文中,我们介绍了MongoDB复制集的架构和特点。我们强调了在生产环境中使用单机版MongoDB的风险,并推荐使用复制集来保证数据的高可用性和冗余性。
复制集由一组Mongod实例组成,其中包含一个Primary节点和多个Secondary节点。所有的数据写入操作都会被写入Primary节点,并且Secondary节点会从Primary节点同步写入的数据,以保持复制集内所有成员存储相同的数据集。
最后,我们提供了在典型三节点复制集环境中搭建的步骤和注意事项,包括准备配置文件和启动MongoDB进程。下一章节我们将讲解如何配置复制集和集群安全验证及其连接方式。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

渣渣兔

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表