MongoDB集群高可用介绍和简单搭建

最新推荐文章于 2024-07-20 08:57:45 发布

biu~biu~biu_

最新推荐文章于 2024-07-20 08:57:45 发布

阅读量1.2k

点赞数

分类专栏： MongoDB 文章标签： mongodb

本文链接：https://blog.csdn.net/Kiven_ch/article/details/119485656

版权

MongoDB 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

文章目录

MongoDB主从复制架构原理和缺陷
复制集replica sets
分片集群 Shard Cluster

MongoDB主从复制架构原理和缺陷

master-slave架构中master节点负责数据的读写，slave没有写入权限只负责读取数据。
在这里插入图片描述

在主从结构中，主节点的操作记录成为oplog（operation log）。oplog存储在系统数据库local的 oplog.$main集合中，这个集合的每个文档都代表主节点上执行的一个操作。从服务器会定期从主服务中获取oplog记录，然后在本机上执行！对于存储oplog的集合，MongoDB采用的是固定集合，也就是说随着操作过多，新的操作会覆盖旧的操作！

主从结构没有自动故障转移功能，需要指定master和slave端，不推荐在生产中使用。

mongodb4.0后不再支持主从复制！

[main] Master/slave replication is no longer supported

复制集replica sets

官网地址
https://docs.mongodb.com/v4.2/replication/

什么是复制集

在这里插入图片描述

复制集是由一组拥有相同数据集的mongod实例做组成的集群。

复制集是一个集群，它是2台及2台以上的服务器组成，以及复制集成员包括Primary主节点,secondary从节点和投票节点。

复制集提供了数据的冗余备份，并在多个服务器上存储数据副本，提高了数据的可用性,保证数据的安全性。

为什么要使用复制集

1.高可用
	防止设备（服务器、网络）故障。
	提供自动failover 功能。
	技术来保证高可用
2.灾难恢复
	当发生故障时，可以从其他节点恢复 用于备份。
3.功能隔离
	我们可以在备节点上执行读操作，减少主节点的压力
	比如:用于分析、报表，数据挖掘，系统任务等。

复制集集群架构原理

一个复制集中Primary节点上能够完成读写操作,Secondary节点仅能用于读操作。Primary节点需要记录所有改变数据库状态的操作,这些记录保存在 oplog 中,这个文件存储在 local 数据库,各个Secondary节点通过此 oplog 来复制数据并应用于本地,保持本地的数据与主节点的一致。oplog 具有幂等性,即无论执行几次其结果一致,这个比 mysql 的二进制日志更好用。

oplog的组成结构

{
	"ts" : Timestamp(1446011584, 2),
	"h" : NumberLong("1687359108795812092"),
	"v" : 2,
	"op" : "i",
	"ns" : "test.nosql",
	"o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb",	"score" : "10"}
}
ts：操作时间，当前timestamp + 计数器，计数器每秒都被重置
h：操作的全局唯一标识
v：oplog版本信息
op：操作类型
	i：插入操作
	u：更新操作
	d：删除操作
c：执行命令（如createDatabase，dropDatabase）
n：空操作，特殊用途
ns：操作针对的集合
o：操作内容
o2：更新查询条件,仅update操作包含该字段

复制集数据同步分为初始化同步和keep复制同步。初始化同步指全量从主节点同步数据，如果Primary节点数据量比较大同步时间会比较长。而keep复制指初始化同步过后，节点之间的实时同步一般是增量同步。

初始化同步有以下两种情况会触发：

(1) Secondary第一次加入。

(2) Secondary落后的数据量超过了oplog的大小，这样也会被全量复制。

MongoDB的Primary节点选举基于心跳触发。一个复制集N个节点中的任意两个节点维持心跳，每个节点维护其他N-1个节点的状态。

在这里插入图片描述

心跳检测：
整个集群需要保持一定的通信才能知道哪些节点活着哪些节点挂掉。mongodb节点会向副本集中的其他节点每2秒就会发送一次pings包，如果其他节点在10秒钟之内没有返回就标示为不能访问。每个节点内部都会维护一个状态映射表，表明当前每个节点是什么角色、日志时间戳等关键信息。如果主节点发现自己无法与大部分节点通讯则把自己降级为secondary只读节点。

复制集的三个角色

副本集有两种类型三种角色
两种类型：

主节点（Primary）类型：数据操作的主要连接点，可读写。
次要（辅助、从）节点（Secondaries）类型：数据冗余备份节点，可以读或选举。

三种角色：

主要成员（Primary）：主要接收所有写操作。就是主节点。
副本成员（Replicate）：从主节点通过复制操作以维护相同的数据集，即备份数据，不可写操作，但可
以读操作（但需要配置）。是默认的一种从节点类型。

仲裁者（Arbiter）：不保留任何数据的副本，只具有投票选举作用。当然也可以将仲裁服务器维护为副本集的一部分，即副本成员同时也可以是仲裁者。也是一种从节点类型。

在这里插入图片描述
关于仲裁者的额外说明：

您可以将额外的mongod实例添加到副本集作为仲裁者。仲裁者不维护数据集。仲裁者的目的是通过响应其他副本集成员的心跳和选举请求来维护副本集中的仲裁。因为它们不存储数据集，所以仲裁器可以是提供副本集仲裁功能的好方法，其资源成本比具有数据集的全功能副本集成员更便宜。

如果您的副本集具有偶数个成员，请添加仲裁者以获得主要选举中的“大多数”投票。仲裁者不需要专用硬件。

仲裁者将永远是仲裁者，而主要人员可能会退出并成为次要人员，而次要人员可能成为选举期间的主要人员。

如果你的副本+主节点的个数是偶数，建议加一个仲裁者，形成奇数，容易满足大多数的投票。

如果你的副本+主节点的个数是奇数，可以不加仲裁者。

主节点选举触发的时机:

第一次初始化一个复制集

Secondary节点权重比Primary节点高时，发起替换选举

Secondary节点发现集群中没有Primary时，发起选举

Primary节点不能访问到大部分(Majority)成员时主动降级

当触发选举时,Secondary节点尝试将自身选举为Primary。主节点选举是一个二阶段过程+多数派协议。

第一阶段:
检测自身是否有被选举的资格如果符合资格会向其它节点发起本节点是否有选举资格的FreshnessCheck,进行同僚仲裁

第二阶段:
发起者向集群中存活节点发送Elect(选举)请求，仲裁者收到请求的节点会执行一系列合法性检查，如果检查通过，则仲裁者(一个复制集中最多50个节点其中只有7个具有投票权)给发起者投一票。

pv0（第一版协议）通过30秒选举锁防止一次选举中两次投票。

pv1（第二版本协议）使用了terms(一个单调递增的选举计数器)来防止在一次选举中投两次票的情况。

多数派协议:
发起者如果获得超过半数的投票，则选举通过，自身成为Primary节点。获得低于半数选票的原因，除了常见的网络问题外，相同优先级的节点同时通过第一阶段的同僚仲裁并进入第二阶段也是一个原因。因此，当选票不足时，会sleep[0,1]秒内的随机时间，之后再次尝试选举。

复制集搭建

在这里插入图片描述

环境准备，我这里使用四台虚拟机进行操作，也可以在一台机器上面使用四个MongoDB程序分别绑定不同的端口进行搭建
准备 MongoDB安装包，解压后进行配置，跟之前的单机模式，主要就是增加了最后的复制集名称，另外两台机器使用相同的配置，值需要修改绑定的ip即可，或者全都绑定0.0.0.0

systemLog:
#MongoDB发送所有日志输出的目标指定为文件
# #The path of the log file to which mongod or mongos should send all diagnostic logging information
    destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
    path: "/root/mongodb/replica/mongodb/log/mongod.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
    logAppend: true
storage:
#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
##The directory where the mongod instance stores its data.Default Value is "/data/db".
    dbPath: "/root/mongodb/replica/mongodb/data/db"
    journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
        enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
    fork: true
net:
#服务实例绑定的IP，默认是localhost
    bindIp: 192.168.31.10
#bindIp
#绑定的端口，默认是27017
    port: 27017
replication:
    replSetName: testCluster

首先启动两台MongoDB进行操作，初始化节点配置，使用mongo客户端连接进入192.168.31.10节点运行如下命令：

var cfg ={"_id":"testCluster",
	"protocolVersion" : 1,
	"members":[
	{"_id":1,"host":"192.168.31.10:27017","priority":10},
	{"_id":2,"host":"192.168.31.13:27017"}]
}
rs.initiate(cfg)
rs.status()

在这里插入图片描述

节点的动态增删

增加节点
rs.add("192.168.31.14:27017")
删除slave 节点
rs.remove("192.168.31.14:27017")

在这里插入图片描述

复制集操作演示
进入主节点 ----- 插入数据 ------ 进入从节点验证
注意:默认节点下从节点不能读取数据。调用 rs.secondaryOk() 解决

testCluster:PRIMARY> use articledb;
switched to db articledb
testCluster:PRIMARY> db.comment.insertOne({'articleid':'456466','content':'搭建分片集群测试','userid':'1003','nickname':'管理员','createdatetime':new ISODate('2021-08-07'),'likenum':NumberInt(99999),'state':'1'});
{
	"acknowledged" : true,
	"insertedId" : ObjectId("610e2a588baba137f3bc4af8")
}
testCluster:PRIMARY>

在这里插入图片描述
直接在从库查询会返回失败，执行rs.secondaryOk()

在这里插入图片描述

为了保证高可用，在集群当中如果主节点挂掉后，会自动在从节点中选举一个重新做为主节点。
rs.status()

节点说明:

PRIMARY 节点：可以查询和新增数据
SECONDARY 节点：只能查询不能新增基于priority 权重可以被选为主节点
ARBITER 节点：不能查询数据和新增数据，不能变成主节点

复制集成员的配置参数

参数字段	类型说明	取值	说明
_id	整数	_id:0	复制集中的标示
host	字符串	host:“主机:端口”	节点主机名
arbiterOnly	布尔值	arbiterOnly:true	是否为仲裁(裁判)节点
priority（权重）	整数	priority=0\|1	默认1，是否有资格变成主节点，取值范围0-1000，0永远不会变成主节点
hidden	布尔值	hidden=true\|false, 0\|1	隐藏，权重必须为0，才可以设置
votes	整数	votes= 0\|1	投票，是否为投票节点,0 不投票，1投票
slaveDelay	整数	slaveDelay=3600	从库的延迟多少秒
buildIndexes	布尔值	buildIndexes=true\|false,0\|1	主库的索引，从库也创建，_id索引无效

举例:

var cfg ={"_id":"testCluster",
		"protocolVersion" : 1,
		"members":[
			{"_id":1,"host":"192.168.31.10:27017","priority":10},
			{"_id":2,"host":"192.168.31.13:27017","priority":0},
			{"_id":3,"host":"192.168.31.14:27017","priority":5},
			{"_id":4,"host":"192.168.31.15:27017","arbiterOnly":true}
		]
	};
	
// 重新装载配置，并重新生成集群节点，只能在primary节点执行。
rs.reconfig(cfg)
//重新查看集群状态
rs.status()

有仲裁节点复制集搭建

和上面的配置步骤相同只是增加了一个特殊的仲裁节点
注入节点执行 rs.addArb(“IP:端口”);
rs.addArb(“192.168.31.15:27017”)

在这里插入图片描述

分片集群 Shard Cluster

什么是分片

分片（sharding）是MongoDB用来将大型集合水平分割到不同服务器（或者复制集）上所采用的方法。不需要功能强大的大型计算机就可以存储更多的数据，处理更大的负载。

为什么要分片

1.存储容量需求超出单机磁盘容量。
2.活跃的数据集超出单机内存容量，导致很多请求都要从磁盘读取数据，影响性能。
3.IOPS超出单个MongoDB节点的服务能力，随着数据的增长，单机实例的瓶颈会越来越明显。
4.副本集具有节点数量限制。

垂直扩展：增加更多的CPU和存储资源来扩展容量。

水平扩展：将数据集分布在多个服务器上。水平扩展即分片。

在这里插入图片描述分片集群由以下3个服务组成：

Shards Server: 每个shard由一个或多个mongod进程组成，用于存储数据。
Router Server: 数据库集群的请求入口，所有请求都通过Router(mongos)进行协调，不需要在应用程序添加一个路由选择器，Router(mongos)就是一个请求分发中心它负责把应用程序的请求转发到对应的Shard服务器上。
Config Server: 配置服务器。存储所有数据库元信息（路由、分片）的配置。

片键（shard key）
为了在数据集合中分配文档，MongoDB使用分片主键分割集合。

区块（chunk）
在一个shard server内部，MongoDB还是会把数据分为chunks，每个chunk代表这个shardserver内部一部分数据。MongoDB分割分片数据到区块，每一个区块包含基于分片主键的左闭右开的区间范围。

分片策略

范围分片（Range based sharding）

范围分片是基于分片主键的值切分数据，每一个区块将会分配到一个范围。

范围分片适合满足在一定范围内的查找，例如查找X的值在[20,30)之间的数据，mongo 路由根据Config server中存储的元数据，可以直接定位到指定的shard的Chunk中。

缺点: 如果shard key有明显递增（或者递减）趋势，则新插入的文档多会分布到同一个chunk，无法扩展写的能力。
hash分片（Hash based sharding）

Hash分片是计算一个分片主键的hash值，每一个区块将分配一个范围的hash值。

Hash分片与范围分片互补，能将文档随机的分散到各个chunk，充分的扩展写能力，弥补了范围分片的不足，缺点是不能高效的服务范围查询，所有的范围查询要分发到后端所有的Shard才能找出满足条件的文档。
组合片键 A + B(散列思想不能是直接hash)
数据库中没有比较合适的片键供选择，或者是打算使用的片键基数太小（即变化少如星期只有7天可变化），可以选另一个字段使用组合片键，甚至可以添加冗余字段来组合。一般是粗粒度+细粒度进行组合。

合理的选择shard key

无非从两个方面考虑，数据的查询和写入，最好的效果就是数据查询时能命中更少的分片，数据写入时能够随机的写入每个分片，关键在于如何权衡性能和负载。

分片集群的搭建过程

在这里插入图片描述

配置并启动config 节点集群

分片部分的配置参考官网:
https://docs.mongodb.com/v4.2/reference/configuration-options/#sharding-options

继续使用上面的多态虚拟机的环境
部署环境如下
在这里插入图片描述
将上面复制集搭建启动的MongoDB先进行关闭

在31.13服务器中进行操作

在mongo目录下下分别创建 config/config1 config/config2 config/config3 三个目录存放配置节点的数据库文件，再创建config/logs用于存放日志文件

[root@MiWiFi-R3L-srv mongodb]# mkdir  -p  config/config1
[root@MiWiFi-R3L-srv mongodb]# mkdir  -p  config/config2
[root@MiWiFi-R3L-srv mongodb]# mkdir  -p  config/config3
[root@MiWiFi-R3L-srv mongodb]# tree config/
config/
├── config1
├── config2
└── config3

config目录下分别创建 config-17017.conf config-17018.conf config-17019.conf三个配置文件

config-17017.conf：

systemLog:
#MongoDB发送所有日志输出的目标指定为文件
# #The path of the log file to which mongod or mongos should send all diagnostic logging information
    destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
    path: "/root/mongodb/mongodb/config/logs/config1.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
    logAppend: true
storage:
#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
##The directory where the mongod instance stores its data.Default Value is "/data/db".
    dbPath: "/root/mongodb/mongodb/config/config1"
    journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
        enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
    fork: true
net:
#服务实例绑定的IP，默认是localhost
    bindIp: 0.0.0.0
#bindIp
#绑定的端口，默认是27017
    port: 17017
replication:
    replSetName: configSvr
sharding:
   clusterRole: configsvr

config-17018.conf：

systemLog:
#MongoDB发送所有日志输出的目标指定为文件
# #The path of the log file to which mongod or mongos should send all diagnostic logging information
    destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
    path: "/root/mongodb/mongodb/config/logs/config2.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
    logAppend: true
storage:
#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
##The directory where the mongod instance stores its data.Default Value is "/data/db".
    dbPath: "/root/mongodb/mongodb/config/config2"
    journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
        enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
    fork: true
net:
#服务实例绑定的IP，默认是localhost
    bindIp: 0.0.0.0
#bindIp
#绑定的端口，默认是27017
    port: 17018
replication:
    replSetName: configSvr
sharding:
   clusterRole: configsvr

config-17019.conf：

systemLog:
#MongoDB发送所有日志输出的目标指定为文件
# #The path of the log file to which mongod or mongos should send all diagnostic logging information
    destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
    path: "/root/mongodb/mongodb/config/logs/config3.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
    logAppend: true
storage:
#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
##The directory where the mongod instance stores its data.Default Value is "/data/db".
    dbPath: "/root/mongodb/mongodb/config/config3"
    journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
        enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
    fork: true
net:
#服务实例绑定的IP，默认是localhost
    bindIp: 0.0.0.0
#bindIp
#绑定的端口，默认是27017
    port: 17019
replication:
    replSetName: configSvr
sharding:
   clusterRole: configsvr

启动三个配置服务端

./bin/mongod -f  config/config-17017.conf
./bin/mongod -f  config/config-17018.conf
./bin/mongod -f  config/config-17019.conf

进入任意节点的mongo shell 并添加配置节点集群注意use admin

./bin/mongo --host 192.168.31.13 --port 17017

use admin;

var cfg ={"_id":"configSvr",
		"protocolVersion" : 1,
		"members":[
			{"_id":1,"host":"192.168.31.13:17017"},
			{"_id":2,"host":"192.168.31.13:17018"},
			{"_id":3,"host":"192.168.31.13:17019"},
		]
	};


rs.initiate(cfg)

在这里插入图片描述

配置shard集群

首先搭建sharding1集群
进入mongo目录创建需要的目录

mkdir -p shard/shard-27017
mkdir -p shard/shard-27018
mkdir -p shard/shard-27019
mkdir -p shard/log

shard目录下创建 mongod-27017.conf mongod-27018.conf mongod-27019.conf
内容如下

mongod-27017.con:

systemLog:
#MongoDB发送所有日志输出的目标指定为文件
# #The path of the log file to which mongod or mongos should send all diagnostic logging information
    destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
    path: "/root/mongodb/mongodb/shard/log/shard-27017.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
    logAppend: true
storage:
#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
##The directory where the mongod instance stores its data.Default Value is "/data/db".
    dbPath: "/root/mongodb/mongodb/shard/shard-27017"
    journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
        enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
    fork: true
net:
#服务实例绑定的IP，默认是localhost
    bindIp: 0.0.0.0
#bindIp
#绑定的端口，默认是27017
    port: 27017
replication:
    replSetName: shard1
sharding:
   clusterRole: shardsvr

mongod-27018.con:

systemLog:
#MongoDB发送所有日志输出的目标指定为文件
# #The path of the log file to which mongod or mongos should send all diagnostic logging information
    destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
    path: "/root/mongodb/mongodb/shard/log/shard-27018.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
    logAppend: true
storage:
#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
##The directory where the mongod instance stores its data.Default Value is "/data/db".
    dbPath: "/root/mongodb/mongodb/shard/shard-27018"
    journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
        enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
    fork: true
net:
#服务实例绑定的IP，默认是localhost
    bindIp: 0.0.0.0
#bindIp
#绑定的端口，默认是27017
    port: 27018
replication:
    replSetName: shard1
sharding:
   clusterRole: shardsvr

mongod-27019.con:

systemLog:
#MongoDB发送所有日志输出的目标指定为文件
# #The path of the log file to which mongod or mongos should send all diagnostic logging information
    destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
    path: "/root/mongodb/mongodb/shard/log/shard-27019.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
    logAppend: true
storage:
#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
##The directory where the mongod instance stores its data.Default Value is "/data/db".
    dbPath: "/root/mongodb/mongodb/shard/shard-27019"
    journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
        enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
    fork: true
net:
#服务实例绑定的IP，默认是localhost
    bindIp: 0.0.0.0
#bindIp
#绑定的端口，默认是27017
    port: 27019
replication:
    replSetName: shard1
sharding:
   clusterRole: shardsvr

启动每个mongod 然后进入其中一个进行集群配置

var cfg ={"_id":"shard1",
		"protocolVersion" : 1,
		"members":[
			{"_id":1,"host":"192.168.31.14:27017","priority":10},
			{"_id":2,"host":"192.168.31.14:27018","priority":0},
			{"_id":3,"host":"192.168.31.14:27019","priority":5},
		]
	};

rs.initiate(cfg)
rs.status()

在31.15机器同样的步骤搭建shard2，这里就不做演示了，唯一要修改的就是复制集名称改为shard2

systemLog:
#MongoDB发送所有日志输出的目标指定为文件
# #The path of the log file to which mongod or mongos should send all diagnostic logging information
    destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
    path: "/root/mongodb/mongodb/shard/log/shard-27018.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
    logAppend: true
storage:
#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
##The directory where the mongod instance stores its data.Default Value is "/data/db".
    dbPath: "/root/mongodb/mongodb/shard/shard-27018"
    journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
        enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
    fork: true
net:
#服务实例绑定的IP，默认是localhost
    bindIp: 0.0.0.0
#bindIp
#绑定的端口，默认是27017
    port: 27018
replication:
    replSetName: shard2
sharding:
   clusterRole: shardsvr


var cfg ={"_id":"shard2",
		"protocolVersion" : 1,
		"members":[
			{"_id":1,"host":"192.168.31.15:27017","priority":10},
			{"_id":2,"host":"192.168.31.15:27018","priority":0},
			{"_id":3,"host":"192.168.31.15:27019","priority":5},
		]
	};

rs.initiate(cfg)
rs.status()

配置和启动路由节点

创建route-27017.conf

systemLog:
#MongoDB发送所有日志输出的目标指定为文件
# #The path of the log file to which mongod or mongos should send all diagnostic logging information
    destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
    path: "/root/mongodb/mongodb/log/mongod.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
    logAppend: true
#storage:
#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
##The directory where the mongod instance stores its data.Default Value is "/data/db".
#    dbPath: "/root/mongodb/mongodb/data/db"
#    journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
#        enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
    fork: true
net:
#服务实例绑定的IP，默认是localhost
    bindIp: localhost,192.168.31.10
#bindIp
#绑定的端口，默认是27017
    port: 27017
#replication:
#    replSetName: testCluster
sharding:
   configDB: configSvr/192.168.31.13:17017,192.168.31.13:17018,192.168.31.13:17019

启动路由节点使用 mongos （注意不是mongod）

./bin/mongos -f route-27017.conf

mongos（路由）中添加分片节点

mongo --port 27017

sh.status()

sh.addShard("shard1/192.168.31.14:27017,192.168.31.14:27018,192.168.31.14:27019");

sh.addShard("shard2/192.168.31.15:27017,192.168.31.15:27018,192.168.31.15:27019");

sh.status()

在这里插入图片描述
开启数据库和集合分片(指定片键),继续使用mongos完成分片开启和分片大小设置

为数据库开启分片功能

sh.enableSharding("shard_test")

为指定集合开启分片功能
sh.shardCollection("shard_test.shard_test_datas",{"name": "hashed"})

向集合中插入数据测试

use shard_test;
for(var i=1;i<= 1000;i++){
db.shard_test_datas.insert({"name":"test"+i,
salary:(Math.random()*20000).toFixed(2)});
}

验证分片效果
分别进入 shard1 和 shard2 中的数据库进行验证
在这里插入图片描述

biu~biu~biu_

关注

0
点赞
踩
7

收藏

觉得还不错? 一键收藏
0
评论
MongoDB集群高可用介绍和简单搭建

MongoDB主从复制架构原理和缺陷master-slave架构中master节点负责数据的读写，slave没有写入权限只负责读取数据。在主从结构中，主节点的操作记录成为oplog（operation log）。oplog存储在系统数据库local的 oplog.$main集合中，这个集合的每个文档都代表主节点上执行的一个操作。从服务器会定期从主服务中获取oplog记录，然后在本机上执行！对于存储oplog的集合，MongoDB采用的是固定集合，也就是说随着操作过多，新的操作会覆盖旧的操作！主从
复制链接

扫一扫