MongoDB学习笔记(五) 集群搭建之副本集

本文涉及的产品
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
简介: MongoDB学习笔记(五) 集群搭建之副本集

常见的MongoDB集群有三种,分别是主从复制、副本集和分片,这篇文章将会对副本集进行简单的介绍

开始先说一下,这篇文章用到的所有代码都是经过本地测试的,博主用于测试的操作系统为 CentOS 7

好,下面正式开始!


1、介绍


之前讲到,主从复制集群利用从节点对主节点的数据进行备份,在主节点发生故障后可以手动恢复数据

但是这里有一个问题,那就是每次当主节点发生故障后,都需要暂停服务并且手动转移数据

不仅十分麻烦,而且暂停服务所带来的损失更是无法估量的,副本集就是为了解决这个问题而出现了

在一个副本集(Replica Set)中,包含多个数据承载节点(Data Bearing)和仲裁节点(Arbiter)

数据承载节点又可以细分为主节点(Primary)和从节点(Secondary),它们各自的描述如下:

  • 主节点:有且仅有一个,默认情况下对客户端提供所有的增删改查服务
  • 从节点:备份主节点数据,可提供查询服务,在主节点挂掉后投票选择一个从节点作为主节点继续提供服务
  • 仲裁节点:不储存数据,不提供服务,仅参与投票,在主节点挂掉后投票选择一个从节点作为主节点


副本集的特征如下:

  • 写操作仅在主节点上,并同步到从节点以保证数据的一致性
  • 读操作既可以在主节点上,也可以在从节点上,在一定程度上可以减轻主节点的负担
  • 当主节点挂掉后,会选举一个从节点作为主节点继续提供服务,因此无需进行停机维护


同步机制

副本集中的同步机制有两种,一种是全量同步,一种是增量同步

全量同步:从节点同步主节点的所有数据,当从节点加入或从节点未同步的数据量超过一定阈值时触发

增量同步:从节点定期同步主节点新修改的数据


自动故障转移机制

副本集的各个节点通过心跳信息检测各自的健康状况

当主节点发生故障时,投票选择一个从节点作为新的主节点,继续提供服务


选举机制

副本集中的选举机制使用的是 Bully 算法,Bully 算法的核心思想如下:

当从节点 A 发现主节点挂掉后,它就会发起选举,发送选举消息给其它节点,然后等待这些节点的回复

假设从节点 B 收到这个消息,并且发现自己的优先级比从节点 A 要大,那么从节点 A 就会退出选举

从节点 B 继续给其它节点发送选举消息,等待这些节点的回复,直到有一个节点能够获得大多数节点的赞同

此时,这个节点向所有节点宣布自己成为新的主节点,然后其它节点更新信息,结束选举过程

注意要进行选举有一个前提条件,那就是参与选举的节点数量必须大于副本集总节点数量的一半


2、搭建


下面是一个简单的模拟,一个主节点,一个从节点,一个仲裁节点


(1)下载 MongoDB


> su
> cd /root
> mkdir mongodb-replica-set-cluster
> cd mongodb-replica-set-cluster


> mkdir mongodb
> cd mongodb
> wget https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-3.2.7.tgz
> tar -zxvf mongodb-linux-x86_64-3.2.7.tgz
> cd ..


(2)创建三个文件夹,分别模拟主节点、从节点和仲裁节点


> mkdir primary # 主节点
> touch ./primary/mongodb.conf
> mkdir ./primary/log
> mkdir -p ./primary/data/db

> mkdir secondary # 从节点
> touch ./secondary/mongodb.conf
> mkdir ./secondary/log
> mkdir -p ./secondary/data/db

> mkdir arbiter # 仲裁节点
> touch ./arbiter/mongodb.conf
> mkdir ./arbiter/log
> mkdir -p ./arbiter/data/db

创建完成之后,目录结构如下

+ mongodb-replica-set-cluster
  + mongodb
    + mongodb-linux-x86_64-3.2.7.tgz
    + mongodb-linux-x86_64-3.2.7
  + primary
    + log
    + data
      + db
    + mongodb.conf
  + secondary
    + log
    + data
      + db
    + mongodb.conf
  + arbiter
    + log
    + data
      + db
    + mongodb.conf


(3)写配置文件


# primary/mongodb.conf 文件内容
# 数据文件的存放位置
dbpath = /root/mongodb-replica-set-cluster/primary/data/db
# 日志文件的存放位置
logpath = /root/mongodb-replica-set-cluster/primary/log/mongodb.log
# 监听的端口,默认为 27017
port = 27001
# 以守护进程的方式运行 MongoDB
fork = true
# 设置 replSet 名称
replSet = repl


# secondary/mongodb.conf 文件内容
# 数据文件的存放位置
dbpath = /root/mongodb-replica-set-cluster/secondary/data/db
# 日志文件的存放位置
logpath = /root/mongodb-replica-set-cluster/secondary/log/mongodb.log
# 监听的端口,默认为 27017
port = 27002
# 以守护进程的方式运行 MongoDB
fork = true
# 设置 replSet 名称
replSet = repl

# arbiter/mongodb.conf 文件内容
# 数据文件的存放位置
dbpath = /root/mongodb-replica-set-cluster/arbiter/data/db
# 日志文件的存放位置
logpath = /root/mongodb-replica-set-cluster/arbiter/log/mongodb.log
# 监听的端口,默认为 27017
port = 27003
# 以守护进程的方式运行 MongoDB
fork = true
# 设置 replSet 名称
replSet = repl


(4)分别开启三个数据库


> cd /root/mongodb-replica-set-cluster/mongodb/mongodb-linux-x86_64-3.2.7/bin/
> ./mongod -f /root/mongodb-replica-set-cluster/primary/mongodb.conf
> ./mongod -f /root/mongodb-replica-set-cluster/secondary/mongodb.conf
> ./mongod -f /root/mongodb-replica-set-cluster/arbiter/mongodb.conf


之后,应该可以看到有三个 MongoDB 进程正在运行

> ps aux | grep mongo


(5)连接到任意一个节点,初始化节点之间的关系


> cd /root/mongodb-replica-set-cluster/mongodb/mongodb-linux-x86_64-3.2.7/bin/
> ./mongo mongodb://127.0.0.1:27001/admin


> rs.initiate({
    "_id": "repl",
    "members": [ // 添加数据承载节点
        {
            "_id": 1,
            "host": "127.0.0.1:27001"
        },
        {
            "_id": 2,
            "host": "127.0.0.1:27002"
        }
    ]
})
// { "ok" : 1 }
repl:OTHER> rs.addArb("127.0.0.1:27003") // 添加仲裁节点
// { "ok" : 1 }
repl:PRIMARY> rs.status() // 在设置成功后,应该可以看到具体的配置信息


3、测试副本集


打开新的终端,连接到主数据库,插入一条数据(可写),之后对其进行查询(可读)

> cd /root/mongodb-replica-set-cluster/mongodb/mongodb-linux-x86_64-3.2.7/bin/
> ./mongo mongodb://127.0.0.1:27001/admin


PRIMARY> db.user.insert({'username': 'Alice', 'password': '123456'}) // 插入数据(可写)
// WriteResult({ "nInserted" : 1 })
PRIMARY> db.user.find() // 查询数据(可读)
// { "username" : "Alice", "password" : "123456" }


打开另外一个终端,连接到从节点,查询在主数据库插入的数据(可读),之后尝试插入一条新的数据(不可写)

> cd /root/mongodb-replica-set-cluster/mongodb/mongodb-linux-x86_64-3.2.7/bin/
> ./mongo mongodb://127.0.0.1:27002/admin


SECONDARY> rs.slaveOk() // 在查询之前需要先设置从节点状态
SECONDARY> db.user.find() // 查询数据(可读)
// { "username" : "Alice", "password" : "123456" }
SECONDARY> db.user.insert({'username': 'Bob', 'password': 'abc'}) // 插入数据(不可写)
// WriteResult({ "writeError" : { "code" : 10107, "errmsg" : "not master" } })

,接下来新开一个终端,手动关闭主节点,模拟主节点挂掉的情况

> cd /root/mongodb-replica-set-cluster/mongodb/mongodb-linux-x86_64-3.2.7/bin/
> ./mongod --shutdown --dbpath /root/mongodb-replica-set-cluster/primary/data/db


然后在连接着 127.0.0.1:27002 的终端里查看当前副本集的状态

SECONDARY> rs.status()


并且可以看到该节点已经成为主节点(注意此时命令行头已经发生改变),可以在里面插入和查询数据

PRIMARY> db.user.insert({'username': 'Bob', 'password': 'abc'}) // 插入数据(可写)
// WriteResult({ "nInserted" : 1 })
PRIMARY> db.user.find() // 查询数据(可读)
// { "username" : "Alice", "password" : "123456" }
// {'username': 'Bob', 'password': 'abc'}



目录
相关文章
|
7月前
|
存储 NoSQL 安全
客户说|知乎核心业务MongoDB集群的平滑上云迁移实践
客户说|知乎核心业务MongoDB集群的平滑上云迁移实践
215 0
|
11月前
|
存储 NoSQL MongoDB
MongoDB 复制(副本集)
10月更文挑战第17天
158 2
MongoDB 复制(副本集)
|
10月前
|
NoSQL 容灾 MongoDB
MongoDB主备副本集方案:两台服务器使用非对称部署的方式实现高可用与容灾备份
在资源受限的情况下,为了实现MongoDB的高可用性,本文探讨了两种在两台服务器上部署MongoDB的方案。方案一是通过主备身份轮换,即一台服务器作为主节点,另一台同时部署备节点和仲裁节点;方案二是利用`priority`设置实现自动主备切换。两者相比,方案二自动化程度更高,适合追求快速故障恢复的场景,而方案一则提供了更多的手动控制选项。文章最后对比了这两种方案与标准三节点副本集的优缺点,指出三节点方案在高可用性和数据一致性方面表现更佳。
747 5
|
12月前
|
存储 NoSQL Shell
MongoDB复制(副本集)总结
这篇文章是关于MongoDB副本集的总结,包括复制原理、设置副本集、案例分析等内容。
226 1
|
存储 运维 NoSQL
轻松上手:逐步搭建你的高可用MongoDB集群(分片)
【8月更文挑战第13天】在数据激增的背景下,传统单机数据库难以胜任。MongoDB作为流行NoSQL数据库,采用分片技术实现水平扩展,有效处理海量数据。分片将数据分散存储,提高并发处理能力和容错性,是高可用架构基石。构建MongoDB集群需理解shard、config server和router三组件协同工作原理。通过具体实例演示集群搭建流程,包括各组件的启动及配置,确保数据高可用性和系统稳定性。合理规划与实践可构建高效稳定的MongoDB集群,满足业务需求并支持未来扩展。
576 0
|
2月前
|
NoSQL MongoDB 数据库
数据库数据恢复—MongoDB数据库数据恢复案例
MongoDB数据库数据恢复环境: 一台操作系统为Windows Server的虚拟机上部署MongoDB数据库。 MongoDB数据库故障: 工作人员在MongoDB服务仍然开启的情况下将MongoDB数据库文件拷贝到其他分区,数据复制完成后将MongoDB数据库原先所在的分区进行了格式化操作。 结果发现拷贝过去的数据无法使用。管理员又将数据拷贝回原始分区,MongoDB服务仍然无法使用,报错“Windows无法启动MongoDB服务(位于 本地计算机 上)错误1067:进程意外终止。”
|
2月前
|
缓存 NoSQL Linux
在CentOS 7系统中彻底移除MongoDB数据库的步骤
以上步骤完成后,MongoDB应该会从您的CentOS 7系统中被彻底移除。在执行上述操作前,请确保已经备份好所有重要数据以防丢失。这些步骤操作需要一些基本的Linux系统管理知识,若您对某一步骤不是非常清楚,请先进行必要的学习或咨询专业人士。在执行系统级操作时,推荐在实施前创建系统快照或备份,以便在出现问题时能够恢复到原先的状态。
217 79
|
2月前
|
存储 NoSQL MongoDB
MongoDB数据库详解-针对大型分布式项目采用的原因以及基础原理和发展-卓伊凡|贝贝|莉莉
MongoDB数据库详解-针对大型分布式项目采用的原因以及基础原理和发展-卓伊凡|贝贝|莉莉
119 8
MongoDB数据库详解-针对大型分布式项目采用的原因以及基础原理和发展-卓伊凡|贝贝|莉莉
|
5月前
|
NoSQL MongoDB 数据库
数据库数据恢复——MongoDB数据库服务无法启动的数据恢复案例
MongoDB数据库数据恢复环境: 一台Windows Server操作系统虚拟机上部署MongoDB数据库。 MongoDB数据库故障: 管理员在未关闭MongoDB服务的情况下拷贝数据库文件。将MongoDB数据库文件拷贝到其他分区后,对MongoDB数据库所在原分区进行了格式化操作。格式化完成后将数据库文件拷回原分区,并重新启动MongoDB服务。发现服务无法启动并报错。

推荐镜像

更多