MongoDB集群和安全

已于 2023-06-25 23:35:24 修改
阅读量862 收藏
点赞数
分类专栏： mongodb 文章标签： mongodb 安全 数据库
于 2023-06-06 23:44:01 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/General_zy/article/details/131074256
版权

目录

副本集-Replica Sets

简介

MongoDB中的副本集（Replica Set）是一组维护相同数据集的mongod服务。 副本集可提供冗余和高可用性，是所有生产部署的基础。

也可以说，副本集类似于有自动故障恢复功能的主从集群。通俗的讲就是用多台机器进行同一数据的异步同步，从而使多台机器拥有同一数据的多个副本，并且当主库当掉时在不需要用户干预的情况下自动切换其他备份服务器做主库。而且还可以利用副本服务器做只读服务器，实现读写分离，提高负载。

（1）冗余和数据可用性

复制提供冗余并提高数据可用性。 通过在不同数据库服务器上提供多个数据副本，复制可提供一定级别的容错功能，以防止丢失单个数据库服务器。

在某些情况下，复制可以提供增加的读取性能，因为客户端可以将读取操作发送到不同的服务上， 在不同数据中心维护数据副本可以增加分布式应用程序的数据位置和可用性。 您还可以为专用目的维护其他副本，例如灾难恢复，报告或备份。

（2）MongoDB中的复制

副本集是一组维护相同数据集的mongod实例。 副本集包含多个数据承载节点和可选的一个仲裁节点。在承载数据的节点中，一个且仅一个成员被视为主节点，而其他节点被视为次要（从）节点。

主节点接收所有写操作。 副本集只能有一个主要能够确认具有{w：“most”}写入关注的写入; 虽然在某些情况下，另一个mongod实例可能暂时认为自己也是主要的。主要记录其操作日志中的数据集的所有更改，即oplog。

在这里插入图片描述
辅助(副本)节点复制主节点的oplog并将操作应用于其数据集，以使辅助节点的数据集反映主节点的数据
集。 如果master不在，则符合条件的slave将举行选举以选出新的master。

（3）主从复制和副本集区别
主从集群和副本集最大的区别就是副本集没有固定的“主节点”；整个集群会选出一个“主节点”，当其挂
掉后，又在剩下的从节点中选中其他节点为“主节点”，副本集总有一个活跃点(主、primary)和一个或多
个备份节点(从、secondary)。

副本集的三个角色

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

两种类型：

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

三种角色：
3. 主要成员（Primary）：主要接收所有写操作。就是主节点。
4. 副本成员（Replicate）：从主节点通过复制操作以维护相同的数据集，即备份数据，不可写操作，但可以读操作（但需要配置）。是默认的一种从节点类型。
5. 仲裁者（Arbiter）：不保留任何数据的副本，只具有投票选举作用。当然也可以将仲裁服务器维护为副
本集的一部分，即副本成员同时也可以是仲裁者。也是一种从节点类型。

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

  1. 您可以将额外的mongod实例添加到副本集作为仲裁者。 仲裁者不维护数据集。 仲裁者的目的是通过响应其他副本集成员的心跳和选举请求来维护副本集中的仲裁。 因为它们不存储数据集，所以仲裁器可以是提供副本集仲裁功能的好方法，其资源成本比具有数据集的全功能副本集成员更便宜。
  2. 如果您的副本集具有偶数个成员，请添加仲裁者以获得主要选举中的“大多数”投票。 仲裁者不需要专用硬件。
  3. 仲裁者将永远是仲裁者，而主要人员可能会退出并成为次要人员，而次要人员可能成为选举期间的主要人员。
  4. 如果你的副本+主节点的个数是偶数，建议加一个仲裁者，形成奇数，容易满足大多数的投票。
  5. 如果你的副本+主节点的个数是奇数，可以不加仲裁者。

副本集架构目标

一主一副本一仲裁：
在这里插入图片描述

副本集的创建

第一步：创建三个节点

主节点

新建或修改配置文件：

systemLog:
	#MongoDB发送所有日志输出的目标指定为文件
	destination: file
	#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
	path: "/mongodb/replica_sets/myrs_27017/log/mongod.log"
	#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
	logAppend: true
storage:
	#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
	dbPath: "/mongodb/replica_sets/myrs_27017/data/db"
	journal:
		#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
		enabled: true
processManagement:
	#启用在后台运行mongos或mongod进程的守护进程模式。
	fork: true
	#指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
	pidFilePath: "/mongodb/replica_sets/myrs_27017/log/mongod.pid"
net:
	#服务实例绑定所有IP，有副作用，副本集初始化的时候，节点名字会自动设置为本地域名，而不是ip
	#bindIpAll: true
	#服务实例绑定的IP
	bindIp: localhost,192.168.0.2
	#bindIp
	#绑定的端口
	port: 27017
replication:
	#副本集的名称
	replSetName: myrs

启动节点服务：

/usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27017/mongod.conf
副本节点

新建或修改配置文件：

systemLog:
	#MongoDB发送所有日志输出的目标指定为文件
	destination: file
	#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
	path: "/mongodb/replica_sets/myrs_27018/log/mongod.log"
	#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
	logAppend: true
storage:
	#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
	dbPath: "/mongodb/replica_sets/myrs_27018/data/db"
	journal:
	#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
		enabled: true
processManagement:
	#启用在后台运行mongos或mongod进程的守护进程模式。
	fork: true
	#指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
	pidFilePath: "/mongodb/replica_sets/myrs_27018/log/mongod.pid"
net:
	#服务实例绑定所有IP，有副作用，副本集初始化的时候，节点名字会自动设置为本地域名，而不是ip
	#bindIpAll: true
	#服务实例绑定的IP
	bindIp: localhost,192.168.0.2
	#bindIp
	#绑定的端口
	port: 27018
replication:
	#副本集的名称
	replSetName: myrs

启动节点服务：

/usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27018/mongod.conf
仲裁节点

新建或修改配置文件：

systemLog:
	#MongoDB发送所有日志输出的目标指定为文件
	destination: file
	#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
	path: "/mongodb/replica_sets/myrs_27019/log/mongod.log"
	#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
	logAppend: true
storage:
	#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
	dbPath: "/mongodb/replica_sets/myrs_27019/data/db"
	journal:
		#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
		enabled: true
processManagement:
	#启用在后台运行mongos或mongod进程的守护进程模式。
	fork: true
	#指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
	pidFilePath: "/mongodb/replica_sets/myrs_27019/log/mongod.pid"
net:
	#服务实例绑定所有IP，有副作用，副本集初始化的时候，节点名字会自动设置为本地域名，而不是ip
	#bindIpAll: true
	#服务实例绑定的IP
	bindIp: localhost,192.168.0.2
	#bindIp
	#绑定的端口
	port: 27019
replication:
	#副本集的名称
	replSetName: myrs

启动节点服务：

/usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27019/mongod.conf

第二步：初始化配置副本集和主节点

使用客户端命令连接任意一个节点，但这里尽量要连接主节点(27017节点)：

/usr/local/mongodb/bin/mongo --host=180.76.159.126 --port=27017

准备初始化新的副本集：

rs.initiate(configuration)

选项：

在这里插入图片描述

rs.initiate()

1）“ok”的值为1，说明创建成功。
2）命令行提示符发生变化，变成了一个从节点角色，此时默认不能读写。稍等片刻，回车，变成主节点。

第三步：查看副本集的配置内容

返回包含当前副本集配置的文档：

rs.conf(configuration)

提示：

  1. rs.config() 是该方法的别名。
  2. configuration：可选，如果没有配置，则使用默认主节点配置。
myrs:PRIMARY> rs.conf()
{
	"_id" : "myrs",
	"version" : 1,
	"protocolVersion" : NumberLong(1),
	"writeConcernMajorityJournalDefault" : true,
	"members" : [
		{
			"_id" : 0,
			"host" : "180.76.159.126:27017",
			"arbiterOnly" : false,
			"buildIndexes" : true,
			"hidden" : false,
			"priority" : 1,
			"tags" : {},
			"slaveDelay" : NumberLong(0),
			"votes" : 1
		}
	],
	"settings" : {
		"chainingAllowed" : true,
		"heartbeatIntervalMillis" : 2000,
		"heartbeatTimeoutSecs" : 10,
		"electionTimeoutMillis" : 10000,
		"catchUpTimeoutMillis" : -1,
		"catchUpTakeoverDelayMillis" : 30000,
		"getLastErrorModes" : {},
		"getLastErrorDefaults" : {
			"w" : 1,
			"wtimeout" : 0
		},
		"replicaSetId" : ObjectId("5d539bdcd6a308e600d126bb")
	}
}

说明：
1） “_id” : “myrs” ：副本集的配置数据存储的主键值，默认就是副本集的名字
2） “members” ：副本集成员数组，此时只有一个： “host” : “180.76.159.126:27017” ，该成员不是仲裁节点： “arbiterOnly” : false ，优先级（权重值）： “priority” : 1,
3） “settings” ：副本集的参数配置。

副本集配置的查看命令，本质是查询的是 system.replset 的表中的数据：

myrs:PRIMARY> use local
switched to db local
myrs:PRIMARY> show collections
oplog.rs
replset.election
replset.minvalid
replset.oplogTruncateAfterPoint
startup_log
system.replset
system.rollback.id
myrs:PRIMARY> db.system.replset.find()
{ "_id" : "myrs", "version" : 1, "protocolVersion" : NumberLong(1),
"writeConcernMajorityJournalDefault" : true, "members" : [ { "_id" : 0, "host" :
"180.76.159.126:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" :
false, "priority" : 1, "tags" : { }, "slaveDelay" : NumberLong(0), "votes" : 1
} ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000,
"heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000,
"catchUpTimeoutMillis" : -1, "catchUpTakeoverDelayMillis" : 30000,
"getLastErrorModes" : { }, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0
}, "replicaSetId" : ObjectId("5d539bdcd6a308e600d126bb") } }
myrs:PRIMARY>

第四步：查看副本集状态

返回包含状态信息的文档。此输出使用从副本集的其他成员发送的心跳包中获得的数据反映副本集的当
前状态。

rs.status()

myrs:PRIMARY> rs.status()
{
"set" : "myrs",
"date" : ISODate("2019-08-14T05:29:45.161Z"),
"myState" : 1,
"term" : NumberLong(1),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"heartbeatIntervalMillis" : NumberLong(2000),
"optimes" : {
"lastCommittedOpTime" : {
"ts" : Timestamp(1565760578, 1),
"t" : NumberLong(1)
},
"readConcernMajorityOpTime" : {
"ts" : Timestamp(1565760578, 1),
"t" : NumberLong(1)
},
"appliedOpTime" : {
"ts" : Timestamp(1565760578, 1),
"t" : NumberLong(1)
},
"durableOpTime" : {
"ts" : Timestamp(1565760578, 1),
"t" : NumberLong(1)
}
},
"lastStableCheckpointTimestamp" : Timestamp(1565760528, 1),
"members" : [
{
"_id" : 0,
"name" : "180.76.159.126:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 419,
"optime" : {
"ts" : Timestamp(1565760578, 1),
"t" : NumberLong(1)
},
"optimeDate" : ISODate("2019-08-14T05:29:38Z"),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "could not find member to sync from",
"electionTime" : Timestamp(1565760476, 2),
"electionDate" : ISODate("2019-08-14T05:27:56Z"),
"configVersion" : 1,
"self" : true,
"lastHeartbeatMessage" : ""
}
],
"ok" : 1,
"operationTime" : Timestamp(1565760578, 1),
"$clusterTime" : {
"clusterTime" : Timestamp(1565760578, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}

1） “set” : “myrs” ：副本集的名字
2） “myState” : 1：说明状态正常
3） “members” ：副本集成员数组，此时只有一个： “name” : “180.76.159.126:27017” ，该成员的
角色是 “stateStr” : “PRIMARY”, 该节点是健康的： “health” : 1 。

第五步：添加副本从节点

在主节点添加从节点，将其他成员加入到副本集：

rs.add(host, arbiterOnly)

选项：
在这里插入图片描述
主机成员的配置文档：

{
	_id: <int>,
	host: <string>, // required
	arbiterOnly: <boolean>,
	buildIndexes: <boolean>,
	hidden: <boolean>,
	priority: <number>,
	tags: <document>,
	slaveDelay: <int>,
	votes: <number>
}

将27018的副本节点添加到副本集中：

myrs:PRIMARY> rs.add("180.76.159.126:27018")
{
	"ok" : 1,
	"operationTime" : Timestamp(1565761757, 1),
	"$clusterTime" : {
	"clusterTime" : Timestamp(1565761757, 1),
	"signature" : {
			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
			"keyId" : NumberLong(0)
		}
	}
}

第六步：添加仲裁从节点

rs.addArb(host)

将27019的仲裁节点添加到副本集中：

myrs:PRIMARY> rs.addArb("180.76.159.126:27019")
{
	"ok" : 1,
	"operationTime" : Timestamp(1565761959, 1),
	"$clusterTime" : {
	"clusterTime" : Timestamp(1565761959, 1),
	"signature" : {
		"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
		"keyId" : NumberLong(0)
		}
	}
}

第七步：副本集的数据读写操作

登录主节点27017，写入和读取数据：

[root@bobohost ~]# /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port
27017
myrs:PRIMARY> use articledb
switched to db articledb
myrs:PRIMARY> db
articledb
myrs:PRIMARY> db.comment.insert({"articleid":"100000","content":"今天天气真好，阳光
明媚","userid":"1001","nickname":"Rose","createdatetime":new Date()})
WriteResult({ "nInserted" : 1 })
myrs:PRIMARY> db.comment.find()
{ "_id" : ObjectId("5d4d2ae3068138b4570f53bf"), "articleid" : "100000",
"content" : "今天天气真好，阳光明媚", "userid" : "1001", "nickname" : "Rose",
"createdatetime" : ISODate("2019-08-09T08:12:19.427Z") }

登录从节点27018，发现，不能读取集合的数据。当前从节点只是一个备份，不是奴隶节点，无法读取数据，写当然更不行。

因为默认情况下，从节点是没有读写权限的，可以增加读的权限，但需要进行设置。
设置读操作权限：说明：设置为奴隶节点，允许在从成员上运行读的操作

语法：

设置读操作权限：

rs.slaveOk()
#或
rs.slaveOk(true)

该命令是 db.getMongo().setSlaveOk() 的简化命令。

现在可实现了读写分离，让主插入数据，让从来读取数据。

如果要取消读权限：

rs.slaveOk(false)

主节点的选举原则

MongoDB在副本集中，会自动进行主节点的选举，主节点选举的触发条件：
1） 主节点故障
2） 主节点网络不可达（默认心跳信息为10秒）
3） 人工干预（rs.stepDown(600)）

选举规则是根据票数来决定谁获胜：

  1. 票数最高，且获得了“大多数”成员的投票支持的节点获胜。
  2. “大多数”的定义为：假设复制集内投票成员数量为N，则大多数为 N/2 + 1。例如：3个投票成员，则大多数的值是2。当复制集内存活成员数量不足大多数时，整个复制集将无法选举出Primary，复制集将无法提供写服务，处于只读状态。
  3. 若票数相同，且都获得了“大多数”成员的投票支持的，数据新的节点获胜。数据的新旧是通过操作日志oplog来对比的。

在获得票数的时候，优先级（priority）参数影响重大：

  1. 可以通过设置优先级（priority）来设置额外票数。优先级即权重，取值为0-1000，相当于可额外增加0-1000的票数，优先级的值越大，就越可能获得多数成员的投票（votes）数。指定较高的值可使成员更有资格成为主要成员，更低的值可使成员更不符合条件。
  2. 默认情况下，优先级的值是1
  3. 选举节点的优先级必须是0，不能是别的值。即不具备选举权，但具有投票权。

修改优先级：

1）先将配置导入cfg变量

myrs:SECONDARY> cfg=rs.conf()

2）然后修改值（ID号默认从0开始）：

myrs:SECONDARY> cfg.members[1].priority=2

3）重新加载配置

myrs:SECONDARY> rs.reconfig(cfg)
{ "ok" : 1 }

稍等片刻会重新开始选举。

完整的连接字符串

MongoDB客户端连接语法：

mongodb://[username:password@]host1[:port1][,host2[:port2],...[,hostN[:portN]]][/[database][?options]]
  • mongodb:// 这是固定的格式，必须要指定。
  • username:password@ 可选项，如果设置，在连接数据库服务器之后，驱动都会尝试登陆这个数据库
  • host1 必须的指定至少一个host, host1 是这个URI唯一要填写的。它指定了要连接服务器的地址。如果要连接复制集，请指定多个主机地址。
  • portX 可选的指定端口，如果不填，默认为27017
  • /database 如果指定username:password@，连接并验证登陆指定数据库。若不指定，默认打开test 数据库。
  • ?options 是连接选项。如果不使用/database，则前面需要加上/。所有连接选项都是键值对name=value，键值对之间通过&或;（分号）隔开

标准的连接格式包含了多个选项(options)，如下所示：

在这里插入图片描述

部署遇到的问题

mongo添加仲裁节点及添加后无反应

退出nosql01的mongodb客户端并结束mongodb进程，重新登陆mongodb客户端后在主节点设置：

db.adminCommand({"setDefaultRWConcern" : 1,"defaultWriteConcern" : {"w" : 2}})

写关注（Write Concern）是 MongoDB 中用于控制写操作确认和持久化的机制。它决定了在写操作完成之前，MongoDB 是否会等待确认，并在数据持久化之前返回响应给客户端。

写关注主要用于以下两个方面：

  1. 写操作确认（Write Acknowledgment）：写关注定义了在返回写操作成功之前，要求副本集中的节点进行确认的数量。确认的节点数量越多，写操作成功的可靠性越高。常见的写关注级别包括：

    • w: 0：不进行任何确认。
    • w: 1：至少有一个节点进行确认。
    • w: majority：大多数节点进行确认。
    • w: N：指定具体节点数量进行确认。

  2. 数据持久化（Journaling）：写关注还可以控制在返回写操作成功之前，MongoDB 是否要求数据先写入磁盘上的日志（journal）文件。启用日志持久化可以提高数据的持久性和可恢复性。

使用适当的写关注级别可以根据应用程序的要求平衡数据可靠性和性能。较高的写关注级别可以提供更高的数据一致性和持久性，但可能会对性能产生一定影响。

需要注意的是，写关注是在每个写操作中指定的，而不是全局设置。在进行写操作时，可以通过选项或参数指定写关注级别，如果未指定，默认将使用数据库或集合的默认写关注级别。

值得一提的是，MongoDB 还提供了其他的配置选项和特性来处理写操作的确认和持久化，如写操作超时时间、读写偏好、事务等。具体的选择和配置应根据应用程序的需求和环境来确定。

Error parsing YAML config file: yaml-cpp: error at line 3, column 8: illegal map value

配置文件格式错误，可以找一个yaml检测网站进行检验并格式化：

在这里插入图片描述

删除成员

方法一

  1. 关闭要删除的成员的mongod实例。

    先用mongo shell连接到该实例，然后用db.shutdownServer()方法关闭实例。

  2. 连接到副本集的当前 primary副本。

    要确定当前的主数据库，请在连接到副本集的任何成员时使用db.isMaster（）。

  3. 以下面两种形式之一使用rs.remove()删除该成员：

    rs.remove("mongod3.example.net:27017")
 
rs.remove("mongod3.example.net")

如果副本集需要选择新的主数据库，则MongoDB可能会短暂断开shell连接。然后，在这种情况下，shell会自动重新连接。即使命令成功执行，Shell也可能显示DBClientCursor::init call() failed错误信息。

方法二

要删除成员，还可以通过手动编辑副本集配置文档完成。

  1. 关闭要删除的成员的mongod实例。

    先用mongo shell连接到该实例，然后用db.shutdownServer()方法关闭实例。

  2. 连接到副本集的当前 primary副本。

    要确定当前的主数据库，请在连接到副本集的任何成员时使用db.isMaster（）

  3. 通过运行rs.conf()方法查看当前配置文档，并确定要删除的成员在member数组中的位置：

    例如:mongod_C.example.net在以下配置文件中的位置是2：

    {
    "_id" : "rs",
    "version" : 7,
    "members" : [
        {
            "_id" : 0,
            "host" : "mongod_A.example.net:27017"
        },
 
        {
            "_id" : 1,
            "host" : "mongod_B.example.net:27017"
        },
 
        {
            "_id" : 2,
            "host" : "mongod_C.example.net:27017"
        }
    ]
}

  4. 将当前配置文档分配给变量cfg：

    cfg = rs.conf()

  5. 修改cfg对象以删除成员。

    例如：要删除mongod_C.example.net:27017，使用以下JavaScript操作：

cfg.members.splice(2,1)

  6. 通过发出以下命令，用新配置覆盖副本集配置文档：

    rs.reconfig（cfg）

  7. 要确认新配置，发出rs.conf（）。

    对于上面的示例，输出为：

{
    "_id" : "rs",
    "version" : 8,
    "members" : [
        {
            "_id" : 0,
            "host" : "mongod_A.example.net:27017"
        },
 
        {
            "_id" : 1,
            "host" : "mongod_B.example.net:27017"
        }
    ]
}

分片集群-Sharded Cluster

分片概念

  1. 分片（sharding）是一种跨多台机器分布数据的方法， MongoDB使用分片来支持具有非常大的数据集
    和高吞吐量操作的部署。

  2. 换句话说：分片(sharding)是指将数据拆分，将其分散存在不同的机器上的过程。有时也用分区
    (partitioning)来表示这个概念。将数据分散到不同的机器上，不需要功能强大的大型计算机就可以储存
    更多的数据，处理更多的负载。

  3. 具有大型数据集或高吞吐量应用程序的数据库系统可以会挑战单个服务器的容量。例如，高查询率会耗
    尽服务器的CPU容量。工作集大小大于系统的RAM会强调磁盘驱动器的I / O容量。

  4. 有两种解决系统增长的方法：垂直扩展和水平扩展。

  5. 垂直扩展意味着增加单个服务器的容量，例如使用更强大的CPU，添加更多RAM或增加存储空间量。可
    用技术的局限性可能会限制单个机器对于给定工作负载而言足够强大。此外，基于云的提供商基于可用
    的硬件配置具有硬性上限。结果，垂直缩放有实际的最大值。

  6. 水平扩展意味着划分系统数据集并加载多个服务器，添加其他服务器以根据需要增加容量。虽然单个机
    器的总体速度或容量可能不高，但每台机器处理整个工作负载的子集，可能提供比单个高速大容量服务
    器更高的效率。扩展部署容量只需要根据需要添加额外的服务器，这可能比单个机器的高端硬件的总体
    成本更低。权衡是基础架构和部署维护的复杂性增加。

  7. MongoDB支持通过分片进行水平扩展。

分片集群包含的组件

MongoDB分片群集包含以下组件：

  • 分片（存储）：每个分片包含分片数据的子集。 每个分片都可以部署为副本集。
  • mongos（路由）：mongos充当查询路由器，在客户端应用程序和分片集群之间提供接口。
  • config servers（“调度”的配置）：配置服务器存储群集的元数据和配置设置。 从MongoDB 3.4开始，必须将配置服务器部署为副本集（CSRS）。

下图描述了分片集群中组件的交互：
在这里插入图片描述
MongoDB在集合级别对数据进行分片，将集合数据分布在集群中的分片上。

分片集群架构目标

两个分片节点副本集（3+3）+一个配置节点副本集（3）+两个路由节点（2），共11个服务节点。
在这里插入图片描述

分片（存储）节点副本集的创建

第一步：部署第一套副本集

准备存放数据和日志的目录：

#-----------myshardrs01
mkdir -p /mongodb/sharded_cluster/myshardrs01_27018/log \ &
mkdir -p /mongodb/sharded_cluster/myshardrs01_27018/data/db \ &
mkdir -p /mongodb/sharded_cluster/myshardrs01_27118/log \ &
mkdir -p /mongodb/sharded_cluster/myshardrs01_27118/data/db \ &
mkdir -p /mongodb/sharded_cluster/myshardrs01_27218/log \ &
mkdir -p /mongodb/sharded_cluster/myshardrs01_27218/data/db

配置文件：

vim /mongodb/sharded_cluster/myshardrs01_27018/mongod.conf

systemLog:
	#MongoDB发送所有日志输出的目标指定为文件
	destination: file
	#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
	path: "/mongodb/sharded_cluster/myshardrs01_27018/log/mongod.log"
	#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
	logAppend: true
storage:
	#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
	dbPath: "/mongodb/sharded_cluster/myshardrs01_27018/data/db"
	journal:
		#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
		enabled: true
processManagement:
	#启用在后台运行mongos或mongod进程的守护进程模式。
	fork: true
	#指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
	pidFilePath: "/mongodb/sharded_cluster/myshardrs01_27018/log/mongod.pid"
net:
	#服务实例绑定所有IP，有副作用，副本集初始化的时候，节点名字会自动设置为本地域名，而不是ip
	#bindIpAll: true
	#服务实例绑定的IP
	bindIp: localhost,192.168.0.2
	#bindIp
	#绑定的端口
	port: 27018
replication:
	#副本集的名称
	replSetName: myshardrs01
sharding:
	#分片角色
	clusterRole: shardsvr

sharding.clusterRole：
在这里插入图片描述
注意：
设置sharding.clusterRole需要mongod实例运行复制。 要将实例部署为副本集成员，请使用
replSetName设置并指定副本集的名称。

启动第一套副本集：一主一副本一仲裁，依次启动三个mongod服务，然后在主节点将仲裁节点和副本加入副本集。

第二步：部署第二套副本集

#-----------myshardrs02
mkdir -p /mongodb/sharded_cluster/myshardrs02_27318/log \ &
mkdir -p /mongodb/sharded_cluster/myshardrs02_27318/data/db \ &
mkdir -p /mongodb/sharded_cluster/myshardrs02_27418/log \ &
mkdir -p /mongodb/sharded_cluster/myshardrs02_27418/data/db \ &
mkdir -p /mongodb/sharded_cluster/myshardrs02_27518/log \ &
mkdir -p /mongodb/sharded_cluster/myshardrs02_27518/data/db

配置文件，需要修改副本集名称：

systemLog:
	#MongoDB发送所有日志输出的目标指定为文件
	destination: file
	#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
	path: "/mongodb/sharded_cluster/myshardrs01_27018/log/mongod.log"
	#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
	logAppend: true
storage:
	#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
	dbPath: "/mongodb/sharded_cluster/myshardrs01_27018/data/db"
	journal:
		#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
		enabled: true
processManagement:
	#启用在后台运行mongos或mongod进程的守护进程模式。
	fork: true
	#指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
	pidFilePath: "/mongodb/sharded_cluster/myshardrs01_27018/log/mongod.pid"
net:
	#服务实例绑定所有IP，有副作用，副本集初始化的时候，节点名字会自动设置为本地域名，而不是ip
	#bindIpAll: true
	#服务实例绑定的IP
	bindIp: localhost,192.168.0.2
	#bindIp
	#绑定的端口
	port: 27018
replication:
	#副本集的名称
	replSetName: myshardrs02
sharding:
	#分片角色
	clusterRole: shardsvr

启动第二套副本集：一主一副本一仲裁的启动方法

第三步：配置节点副本集的创建

#-----------configrs
#建立数据节点data和日志目录
mkdir -p /mongodb/sharded_cluster/myconfigrs_27019/log \ &
mkdir -p /mongodb/sharded_cluster/myconfigrs_27019/data/db \ &
mkdir -p /mongodb/sharded_cluster/myconfigrs_27119/log \ &
mkdir -p /mongodb/sharded_cluster/myconfigrs_27119/data/db \ &
mkdir -p /mongodb/sharded_cluster/myconfigrs_27219/log \ &
mkdir -p /mongodb/sharded_cluster/myconfigrs_27219/data/db

配置文件：

systemLog:
	#MongoDB发送所有日志输出的目标指定为文件
	destination: file
	#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
	path: "/mongodb/sharded_cluster/myconfigrs_27019/log/mongod.log"
	#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
	logAppend: true
storage:
	#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
	dbPath: "/mongodb/sharded_cluster/myconfigrs_27019/data/db"
	journal:
		#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
		enabled: true
processManagement:
	#启用在后台运行mongos或mongod进程的守护进程模式。
	fork: true
	#指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
	pidFilePath: "/mongodb/sharded_cluster/myconfigrs_27019/log/mongod.pid"
net:
	#服务实例绑定所有IP
	#bindIpAll: true
	#服务实例绑定的IP
	bindIp: localhost,192.168.0.2
	#绑定的端口
	port: 27019
replication:
	replSetName: myconfigrs
sharding:
	clusterRole: configsvr

启动配置副本集：一主两副本

myshardrs01:PRIMARY> rs.add("180.76.159.126:27119")
myshardrs01:PRIMARY> rs.add("180.76.159.126:27219")

第四步：路由节点的创建和操作

第一个路由节点的创建和连接

配置文件：

systemLog:
	#MongoDB发送所有日志输出的目标指定为文件
	destination: file
	#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
	path: "/mongodb/sharded_cluster/mymongos_27017/log/mongod.log"
	#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
	logAppend: true
processManagement:
	#启用在后台运行mongos或mongod进程的守护进程模式。
	fork: true
	#指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
	pidFilePath: /mongodb/sharded_cluster/mymongos_27017/log/mongod.pid"
net:
	#服务实例绑定所有IP，有副作用，副本集初始化的时候，节点名字会自动设置为本地域名，而不是ip
	#bindIpAll: true
	#服务实例绑定的IP
	bindIp: localhost,192.168.0.2
	#bindIp
	#绑定的端口
	port: 27017
sharding:
	#指定配置节点副本集
	configDB:
	myconfigrs/180.76.159.126:27019,180.76.159.126:27119,180.76.159.126:27219

启动mongos：

/usr/local/mongodb/bin/mongos -f /mongodb/sharded_cluster/mymongos_27017/mongos.conf

客户端登录mongos，

/usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27017

此时，写不进去数据，如果写数据会报错：

mongos> use aadb
switched to db aadb
mongos> db.aa.insert({aa:"aa"})
WriteCommandError({
"ok" : 0,
"errmsg" : "unable to initialize targeter for write op for collection
aa.aa :: caused by :: Database aa not found :: caused by :: No shards found",
"code" : 70,
"codeName" : "ShardNotFound",
"operationTime" : Timestamp(1564600123, 2),
"$clusterTime" : {
"clusterTime" : Timestamp(1564600123, 2),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
})

原因：
通过路由节点操作，现在只是连接了配置节点，还没有连接分片数据节点，因此无法写入业务数据

在路由节点上进行分片配置操作

使用命令添加分片：
（1）添加分片：
语法：

sh.addShard("IP:Port")

将第一套分片副本集添加进来：

mongos>
sh.addShard("myshardrs01/192.168.0.2:27018,180.76.159.126:27118,180.76.159.126:2
7218")
{
	"shardAdded" : "myshardrs01",
	"ok" : 1,
	"operationTime" : Timestamp(1564611970, 4),
	"$clusterTime" : {
	"clusterTime" : Timestamp(1564611970, 4),
	"signature" : {
		"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
		"keyId" : NumberLong(0)
		}
	}
}

查看分片状态情况：

mongos> sh.status()

继续将第二套分片副本集添加进来：

sh.addShard("myshardrs02/192.168.0.2:27318,180.76.159.126:27418,180.76.159.126:27518")

提示：如果添加分片失败，需要先手动移除分片，检查添加分片的信息的正确性后，再次添加分片。

移除分片参考(了解)：

use admin
db.runCommand( { removeShard: "myshardrs02" } )

注意：如果只剩下最后一个shard，是无法删除的。
移除时会自动转移分片数据，需要一个时间过程。
完成后，再次执行删除分片命令才能真正删除。

（2）开启分片功能：sh.enableSharding(“库名”)、sh.shardCollection(“库名.集合名”,{“key”:1})

在mongos上的articledb数据库配置sharding:

mongos> sh.enableSharding("articledb")
{
	"ok" : 1,
	"operationTime" : Timestamp(1564612296, 5),
	"$clusterTime" : {
	"clusterTime" : Timestamp(1564612296, 5),
	"signature" : {
		"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
		"keyId" : NumberLong(0)
		}
	}
}

查看分片状态：

mongos> sh.status()
--- Sharding Status ---
sharding version: {
"_id" : 1,
"minCompatibleVersion" : 5,
"currentVersion" : 6,
"clusterId" : ObjectId("5d4211b798f3f9a48522c68b")
}
shards:
{ "_id" : "myshardrs01", "host" :
"myshardrs01/180.76.159.126:27018,180.76.159.126:27118", "state" : 1 }
{ "_id" : "myshardrs02", "host" :
"myshardrs02/180.76.159.126:27318,180.76.159.126:27418", "state" : 1 }
active mongoses:
"4.0.10" : 1
autosplit:
Currently enabled: yes
balancer:
Currently enabled: yes
Currently running: no
Failed balancer rounds in last 5 attempts: 0
Migration Results for the last 24 hours:
No recent migrations
databases:
{ "_id" : "articledb", "primary" : "myshardrs02", "partitioned" :
true, "version" : { "uuid" : UUID("788c9a3b-bb6a-4cc2-a597-974694772986"),
"lastMod" : 1 } }
{ "_id" : "config", "primary" : "config", "partitioned" : true }
config.system.sessions
shard key: { "_id" : 1 }
unique: false
balancing: true
chunks:
myshardrs01 1
{ "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey"
: 1 } } on : myshardrs01 Timestamp(1, 0)

（3）集合分片

对集合分片，你必须使用 sh.shardCollection() 方法指定集合和分片键。

语法：

sh.shardCollection(namespace, key, unique)

参数：
在这里插入图片描述
对集合进行分片时,你需要选择一个 片键（Shard Key） , shard key 是每条记录都必须包含的,且建立了
索引的单个字段或复合字段,MongoDB按照片键将数据划分到不同的 数据块 中,并将 数据块 均衡地分布
到所有分片中.为了按照片键划分数据块,MongoDB使用 基于哈希的分片方式（随机平均分配）或者基
于范围的分片方式（数值大小分配） 。
用什么字段当片键都可以，如：nickname作为片键，但一定是必填字段。

分片规则一：哈希策略

对于 基于哈希的分片 ,MongoDB计算一个字段的哈希值,并用这个哈希值来创建数据块.

在使用基于哈希分片的系统中,拥有”相近”片键的文档 很可能不会 存储在同一个数据块中,因此数据的分离性更好一些.

使用nickname作为片键，根据其值的哈希值进行数据分片

mongos> sh.shardCollection("articledb.comment",{"nickname":"hashed"})
{
"collectionsharded" : "articledb.comment",
"collectionUUID" : UUID("ddea6ed8-ee61-4693-bd16-196acc3a45e8"),
"ok" : 1,
"operationTime" : Timestamp(1564612840, 28),
"$clusterTime" : {
"clusterTime" : Timestamp(1564612840, 28),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}

查看分片状态：sh.status()

databases:
{ "_id" : "articledb", "primary" : "myshardrs02", "partitioned" :
true, "version" : { "uuid" : UUID("251436b7-86c2-4cd8-9a88-70874af29364"),
"lastMod" : 1 } }
articledb.comment
shard key: { "nickname" : "hashed" }
unique: false
balancing: true
chunks:
myshardrs01 2
myshardrs02 2
{ "nickname" : { "$minKey" : 1 } } -->> { "nickname" :
NumberLong("-4611686018427387902") } on : myshardrs01 Timestamp(1, 0)
{ "nickname" : NumberLong("-4611686018427387902") } -->>
{ "nickname" : NumberLong(0) } on : myshardrs01 Timestamp(1, 1)
{ "nickname" : NumberLong(0) } -->> { "nickname" :
NumberLong("4611686018427387902") } on : myshardrs02 Timestamp(1, 2)
{ "nickname" : NumberLong("4611686018427387902") } -->>
{ "nickname" : { "$maxKey" : 1 } } on : myshardrs02 Timestamp(1, 3)
{ "_id" : "config", "primary" : "config", "partitioned" : true }
config.system.sessions
shard key: { "_id" : 1 }
unique: false
balancing: true
chunks:
myshardrs01 1
{ "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey"
: 1 } } on : myshardrs01 Timestamp(1, 0)

分片规则二：范围策略

对于 基于范围的分片 ,MongoDB按照片键的范围把数据分成不同部分.假设有一个数字的片键:想象一个
从负无穷到正无穷的直线,每一个片键的值都在直线上画了一个点.MongoDB把这条直线划分为更短的不
重叠的片段,并称之为 数据块 ,每个数据块包含了片键在一定范围内的数据.

在使用片键做范围划分的系统中,拥有”相近”片键的文档很可能存储在同一个数据块中,因此也会存储在同
一个分片中.

如使用作者年龄字段作为片键，按照点赞数的值进行分片：

mongos> sh.shardCollection("articledb.author",{"age":1})

注意的是：
1）一个集合只能指定一个片键，否则报错。
2）一旦对一个集合分片，分片键和分片值就不可改变。 如：不能给集合选择不同的分片键、不能更新
分片键的值。
3）根据age索引进行分配数据。

查看分片状态：

articledb.author
shard key: { "age" : 1 }
unique: false
balancing: true
chunks:
myshardrs01 1
{ "age" : { "$minKey" : 1 } } -->> { "age" : { "$maxKey"
: 1 } } on : myshardrs01 Timestamp(1, 0
基于范围的分片方式与基于哈希的分片方式性能对比

基于范围的分片方式提供了更高效的范围查询,给定一个片键的范围,分发路由可以很简单地确定哪个数
据块存储了请求需要的数据,并将请求转发到相应的分片中.

不过,基于范围的分片会导致数据在不同分片上的不均衡,有时候,带来的消极作用会大于查询性能的积极
作用.比如,如果片键所在的字段是线性增长的,一定时间内的所有请求都会落到某个固定的数据块中,最终
导致分布在同一个分片中.在这种情况下,一小部分分片承载了集群大部分的数据,系统并不能很好地进行
扩展.

与此相比,基于哈希的分片方式以范围查询性能的损失为代价,保证了集群中数据的均衡.哈希值的随机性
使数据随机分布在每个数据块中,因此也随机分布在不同分片中.但是也正由于随机性,一个范围查询很难
确定应该请求哪些分片,通常为了返回需要的结果,需要请求所有分片.

如无特殊情况，一般推荐使用 Hash Sharding。

而使用 _id 作为片键是一个不错的选择，因为它是必有的，你可以使用数据文档 _id 的哈希作为片键。
这个方案能够是的读和写都能够平均分布，并且它能够保证每个文档都有不同的片键所以数据块能够很
精细。

似乎还是不够完美，因为这样的话对多个文档的查询必将命中所有的分片。虽说如此，这也是一种比较
好的方案了。

理想化的 shard key 可以让 documents 均匀地在集群中分布：
在这里插入图片描述
显示集群的详细信息：

mongos> db.printShardingStatus()

查看均衡器是否工作（需要重新均衡时系统才会自动启动，不用管它）：

mongos> sh.isBalancerRunning()
false

查看当前Balancer状态：

mongos> sh.getBalancerState()
true
分片后插入数据测试

测试一（哈希规则）：登录mongs后，向comment循环插入1000条数据做测试：

mongos> use articledb
switched to db articledb
mongos> for(var i=1;i<=1000;i++)
{db.comment.insert({_id:i+"",nickname:"BoBo"+i})}
WriteResult({ "nInserted" : 1 })
mongos> db.comment.count()
1000

提示：js的语法，因为mongo的shell是一个JavaScript的shell。
注意：从路由上插入的数据，必须包含片键，否则无法插入。

分别登陆两个片的主节点，统计文档数量
第一个分片副本集：
/usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27018

myshardrs01:PRIMARY> use articledb
switched to db articledb
myshardrs01:PRIMARY> db.comment.count()
508

第二个分片副本集：
/usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27318

myshardrs02:PRIMARY> use articledb
switched to db articledb
myshardrs02:PRIMARY> db.comment.count()
493

可以看到，1000条数据近似均匀的分布到了2个shard上。是根据片键的哈希值分配的。
这种分配方式非常易于水平扩展：一旦数据存储需要更大空间，可以直接再增加分片即可，同时提升了
性能。

使用db.comment.stats()查看单个集合的完整情况，mongos执行该命令可以查看该集合的数据分片的
情况。

使用sh.status()查看本库内所有集合的分片信息。

提示：

如果查看状态发现没有分片，则可能是由于以下原因造成了：
1）系统繁忙，正在分片中。
2）数据块（chunk）没有填满，默认的数据块尺寸（chunksize）是64M，填满后才会考虑向其他片的
数据块填充数据，因此，为了测试，可以将其改小，这里改为1M，操作如下：

use config
db.settings.save( { _id:"chunksize", value: 1 } )

测试完改回来：

db.settings.save( { _id:"chunksize", value: 64 } )

注意：要先改小，再设置分片。为了测试，可以先删除集合，重新建立集合的分片策略，再插入数据测
试即可。

再增加一个路由节点

保持配置节点不变：

configDB:
	myconfigrs/180.76.159.126:27019,180.76.159.126:27119,180.76.159.126:27219

启动mongos2：

/usr/local/mongodb/bin/mongos -f /mongodb/sharded_cluster/mymongos_27117/mongos.conf

使用mongo客户端登录27117，发现，第二个路由无需配置，因为分片配置都保存到了配置服务器中
了。

连接分片集群

#连接路由字符串
uri: mongodb://180.76.159.126:27017,180.76.159.126:27117/articledb

清除所有的节点数据（备用）

如果在搭建分片的时候有操作失败或配置有问题，需要重新来过的，可以进行如下操作：

  1. 第一步：查询出所有的测试服务节点的进程：

    [root@bobohost sharded_cluster]# ps -ef |grep mongo

  2. 根据上述的进程编号，依次中断进程：

    kill -2 进程编号

  3. 第二步：清除所有的节点的数据：

    rm -rf /mongodb/sharded_cluster/myconfigrs_27019/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myconfigrs_27119/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myconfigrs_27219/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myshardrs01_27018/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myshardrs01_27118/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myshardrs01_27218/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myshardrs02_27318/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myshardrs02_27418/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myshardrs02_27518/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/mymongos_27017/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/mymongos_27117/data/db/*.*

  4. 第三步：查看或修改有问题的配置

  5. 第四步：依次启动所有节点，不包括路由节点

  6. 第五步：对两个数据分片副本集和一个配置副本集进行初始化和相关配置

  7. 第六步：检查路由mongos的配置，并启动mongos

  8. 第七步：mongo登录mongos，在其上进行相关操作。

安全认证

默认情况下，MongoDB实例启动运行时是没有启用用户访问权限控制的，也就是说，在实例本机服务
器上都可以随意连接到实例进行各种操作，MongoDB不会对连接客户端进行用户验证，这是非常危险
的。

为了能保障mongodb的安全可以做以下几个步骤：
1）使用新的端口，默认的27017端口如果一旦知道了ip就能连接上，不太安全。
2）设置mongodb的网络环境，最好将mongodb部署到公司服务器内网，这样外网是访问不到的。公
司内部访问使用vpn等。
3）开启安全认证。认证要同时设置服务器之间的内部认证方式，同时要设置客户端连接到集群的账号
密码认证方式。

为了强制开启用户访问控制(用户验证)，则需要在MongoDB实例启动时使用选项 --auth 或在指定启动
配置文件中添加选项 auth=true 。

1）启用访问控制：

MongoDB使用的是基于角色的访问控制(Role-Based Access Control,RBAC)来管理用户对实例的访问。
通过对用户授予一个或多个角色来控制用户访问数据库资源的权限和数据库操作的权限，在对用户分配
角色之前，用户无法访问实例。
在实例启动时添加选项 --auth 或指定启动配置文件中添加选项 auth=true 。

2）角色：

在MongoDB中通过角色对用户授予相应数据库资源的操作权限，每个角色当中的权限可以显式指定，
也可以通过继承其他角色的权限，或者两都都存在的权限。

3）权限：

权限由指定的数据库资源(resource)以及允许在指定资源上进行的操作(action)组成。

  1. 资源(resource)包括：数据库、集合、部分集合和集群；
  2. 操作(action)包括：对资源进行的增、删、改、查(CRUD)操作。
    在角色定义时可以包含一个或多个已存在的角色，新创建的角色会继承包含的角色所有的权限。在同一
    个数据库中，新创建角色可以继承其他角色的权限，在 admin 数据库中创建的角色可以继承在其它任意
    数据库中角色的权限。

关于角色权限的查看，可以通过如下命令查询（了解）：

// 查询所有角色权限(仅用户自定义角色)
> db.runCommand({ rolesInfo: 1 })
// 查询所有角色权限(包含内置角色)
> db.runCommand({ rolesInfo: 1, showBuiltinRoles: true })
// 查询当前数据库中的某角色的权限
> db.runCommand({ rolesInfo: "<rolename>" })
// 查询其它数据库中指定的角色权限
> db.runCommand({ rolesInfo: { role: "<rolename>", db: "<database>" } }
// 查询多个角色权限
> db.runCommand(
	{
		rolesInfo: [
		"<rolename>",
		{ role: "<rolename>", db: "<database>" },
		...
		]
	}
)

示例：
查看所有内置角色：

> db.runCommand({ rolesInfo: 1, showBuiltinRoles: true })
{
"roles" : [
{
"role" : "__queryableBackup",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "__system",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "backup",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "clusterAdmin",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "clusterManager",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "clusterMonitor",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "dbAdmin",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "dbAdminAnyDatabase",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "dbOwner",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "enableSharding",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "hostManager",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "read",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "readAnyDatabase",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "readWrite",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "readWriteAnyDatabase",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "restore",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "root",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "userAdmin",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
},
{
"role" : "userAdminAnyDatabase",
"db" : "admin",
"isBuiltin" : true,
"roles" : [ ],
"inheritedRoles" : [ ]
}
],
"ok" : 1
}

常用的内置角色

  1. 数据库用户角色：read、readWrite;
  2. 所有数据库用户角色：readAnyDatabase、readWriteAnyDatabase、userAdminAnyDatabase、dbAdminAnyDatabase
  3. 数据库管理角色：dbAdmin、dbOwner、userAdmin；
  4. 集群管理角色：clusterAdmin、clusterManager、clusterMonitor、hostManager；
  5. 备份恢复角色：backup、restore；
  6. 超级用户角色：root
  7. 内部角色：system

角色说明：
在这里插入图片描述

要删除MongoDB中的角色，可以使用以下命令：

db.dropRole("roleName")

其中，roleName是要删除的角色的名称。请注意，执行此命令需要具有足够的权限，例如userAdmin或dbAdmin角色。

请谨慎使用该命令，确保只删除不再需要的角色，并确保没有任何用户依赖于该角色的权限。

要删除MongoDB中的用户，可以使用db.dropUser()方法。以下是删除用户的命令格式：

db.dropUser("<username>")

其中，<username>是要删除的用户的用户名。

请注意，执行此命令需要具有适当的权限。您需要使用具有适当权限的用户进行身份验证，并在具有适当权限的数据库上执行该命令。

以下是一个示例，演示如何删除名为"myuser"的用户：

use admin
db.dropUser("myuser")

这将从admin数据库中删除名为"myuser"的用户。请替换为要删除的实际用户名和数据库名称。

请谨慎操作，确保您具有足够的权限和正确的身份验证信息，以避免意外删除用户或导致安全问题。

单实例环境

增加mongod的单实例的安全认证功能，可以在服务搭建的时候直接添加，也可以在之前搭建好的服务
上添加。

本文使用之前搭建好的服务，因此，先停止之前的服务

停止服务的方式有两种：快速关闭和标准关闭，下面依次说明：

（1）快速关闭方法（快速，简单，数据可能会出错）
目标：通过系统的kill命令直接杀死进程：
杀完要检查一下，避免有的没有杀掉

#通过进程编号关闭节点
kill -2 54410

【补充】如果一旦是因为数据损坏，则需要进行如下操作（了解）：

# 删除lock文件：
rm -f /mongodb/single/data/db/*.lock
# 修复数据：
/usr/local/mongodb/bin/mongod --repair --dbpath=/mongodb/single/data/db

（2）标准的关闭方法（数据不容易出错，但麻烦）：
目标：通过mongo客户端中的shutdownServer命令来关闭服务
主要的操作步骤参考如下：

//客户端登录服务，注意，这里通过localhost登录，如果需要远程登录，必须先登录认证才行。
mongo --port 27017
//#切换到admin库
use admin
//关闭服务
db.shutdownServer()

添加用户和权限

在服务运行时创建两个管理员用户，一个是系统的超级管理员 myroot ，一个是admin库的管理用户myadmin ：

//切换到admin库
> use admin
//创建系统超级用户 myroot,设置密码123456，设置角色root
//> db.createUser({user:"myroot",pwd:"123456",roles:[ { "role" : "root", "db" :"admin" } ]})
//或
> db.createUser({user:"myroot",pwd:"123456",roles:["root"]})
//创建专门用来管理admin库的账号myadmin，只用来作为用户权限的管理
> db.createUser({user:"myadmin",pwd:"123456",roles:
[{role:"userAdminAnyDatabase",db:"admin"}]})
//查看已经创建了的用户的情况：
> db.system.users.find()
//删除用户
> db.dropUser("myadmin")
true
//修改密码
> db.changeUserPassword("myroot", "123456")

1）本案例创建了两个用户，分别对应超管和专门用来管理用户的角色，事实上，你只需要一个用户即
可。如果你对安全要求很高，防止超管泄漏，则不要创建超管用户。

2）和其它数据库（MySQL）一样，权限的管理都差不多一样，也是将用户和权限信息保存到数据库对
应的表中。Mongodb存储所有的用户信息在admin 数据库的集合system.users中，保存用户名、密码和数据库信息。

3）如果不指定数据库，则创建的指定的权限的用户在所有的数据库上有效，如 {role:“userAdminAnyDatabase”, db:“”}

测试添加的用户是否正确：

//切换到admin
> use admin
//密码输错
> db.auth("myroot","12345")
Error: Authentication failed.
0
//密码正确
> db.auth("myroot","123456")
1

创建普通用户可以在没有开启认证的时候添加，也可以在开启认证之后添加，但开启认证之后，必须使
用有操作admin库的用户登录认证后才能操作。底层都是将用户信息保存在了admin数据库的集合system.users中。

//创建(切换)将来要操作的数据库articledb,
> use articledb
switched to db articledb
//创建用户，拥有articledb数据库的读写权限readWrite，密码是123456
> db.createUser({user: "bobo", pwd: "123456", roles: [{ role: "readWrite", db:
"articledb" }]})
//> db.createUser({user: "bobo", pwd: "123456", roles: ["readWrite"]})
//测试是否可用
> db.auth("bobo","123456")

提示：
如果开启了认证后，登录的客户端的用户必须使用admin库的角色，如拥有root角色的myadmin用
户，再通过myadmin用户去创建其他角色的用户。

服务端开启认证和客户端连接登录

在mongo客户端中使用shutdownServer命令来关闭服务：

> db.shutdownServer()
shutdown command only works with the admin database; try 'use admin'
> use admin
switched to db admin
> db.shutdownServer()

需要几个条件：
必须是在admin库下执行该关闭服务命令。
如果没有开启认证，必须是从localhost登陆的，才能执行关闭服务命令。
非localhost的、通过远程登录的，必须有登录且必须登录用户有对admin操作权限才可以。

在mongod.conf配置文件中加入：

security:
	#开启授权认证
	authorization: enabled

重启客户端，连接时直接认证：

对articledb数据库进行登录认证和相关操作：

[root@bobohost bin]# /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port
27017 --authenticationDatabase articledb -u bobo -p 123456
MongoDB shell version v4.0.10
connecting to: mongodb://180.76.159.126:27017/?
authSource=articledb&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("e5d4148f-373b-45b8-9cff-a927ce617100")
}
MongoDB server version: 4.0.10
> use articledb
switched to db articledb
> db.comment.find()

提示：

  1. -u ：用户名
  2. -p ：密码
  3. –authenticationDatabase ：指定连接到哪个库。当登录是指定用户名密码时，必须指定对应的数据库！

uri连接：

使用用户名和密码连接到 MongoDB 服务器，你必须使用
‘username:password@hostname/dbname’ 格式，'username’为用户名，‘password’ 为密码。

uri: mongodb://bobo:123456@180.76.159.126:27017/articledb

也可以在命令行界面直接：

# 连接mongodb
mongo "mongouri"

副本集环境

在这里插入图片描述
对副本集执行访问控制需要配置两个方面:

1）副本集和共享集群的各个节点成员之间使用内部身份验证，可以使用密钥文件或x.509证书。密钥文
件比较简单，本文使用密钥文件，官方推荐如果是测试环境可以使用密钥文件，但是正式环境，官方推
荐x.509证书。原理就是，集群中每一个实例彼此连接的时候都检验彼此使用的证书的内容是否相同。
只有证书相同的实例彼此才可以访问

2）使用客户端连接到mongodb集群时，开启访问授权。对于集群外部的访问。如通过可视化客户端，
或者通过代码连接的时候，需要开启授权。

在keyfile身份验证中，副本集中的每个mongod实例都使用keyfile的内容作为共享密码，只有具有正确
密钥文件的mongod或者mongos实例可以连接到副本集。密钥文件的内容必须在6到1024个字符之
间，并且在unix/linux系统中文件所有者必须有对文件至少有读的权限。

关闭已开启的副本集服务（可选）

目标：通过mongo客户端中的shutdownServer命令来依次关闭各个服务
关闭副本集中的服务，建议依次关闭仲裁节点、副本节点、主节点。主要的操作步骤参考如下：

//客户端登录服务，注意，这里通过localhost登录，如果需要远程登录，必须先登录认证才行。
mongo --port 27017
//告知副本集说本机要下线
rs.stepDown()
//#切换到admin库
use admin
//关闭服务
db.shutdownServer()

通过主节点添加一个管理员帐号

只需要在主节点上添加用户，副本集会自动同步。开启认证之前，创建超管用户：myroot，密码：123456

myrs:PRIMARY> use admin
switched to db admin
myrs:PRIMARY> db.createUser({user:"myroot",pwd:"123456",roles:["root"]})
Successfully added user: { "user" : "myroot", "roles" : [ "root" ] }

创建副本集认证的key文件

第一步：生成一个key文件到当前文件夹中。

可以使用任何方法生成密钥文件。例如，以下操作使用openssl生成密码文件，然后使用chmod来更改
文件权限，仅为文件所有者提供读取权限

[root@bobohost ~]# openssl rand -base64 90 -out ./mongo.keyfile
[root@bobohost ~]# chmod 400 ./mongo.keyfile
[root@bobohost ~]# ll mongo.keyfile
-r--------. 1 root root 122 8月 14 14:23 mongo.keyfile

所有副本集节点都必须要用同一份keyfile，一般是在一台机器上生成，然后拷贝到其他机器上，且必须
有读的权限，否则将来会报错permissions on /mongodb/replica_sets/myrs_27017/mongo.keyfile are too open

一定要保证密钥文件一致，文件位置随便。但是为了方便查找，建议每台机器都放到一个固定的位置，
都放到和配置文件一起的目录中。

修改配置文件指定keyfile

security:
	#KeyFile鉴权文件
	keyFile: /mongodb/replica_sets/myrs_27017/mongo.keyfile
	#开启认证方式运行
	authorization: enabled

重新启动副本集

如果副本集是开启状态，则先分别关闭关闭复本集中的每个mongod，从次节点开始。直到副本集的所
有成员都离线，包括任何仲裁者。主节点必须是最后一个成员关闭以避免潜在的回滚。

#通过进程编号关闭三个节点
kill -2 54410 54361 54257

【补充】
如果一旦是因为数据损坏，则需要进行如下操作（了解）：
1）删除lock文件：

rm -f /mongodb/replica_sets/myrs_27017/data/db/*.lock \
/mongodb/replica_sets/myrs_27018/data/db/*.lock \
/mongodb/replica_sets/myrs_27019/data/db/mongod.lock \

2）依次修复数据：

/usr/local/mongodb/bin/mongod --repair --
dbpath=/mongodb/replica_sets/myrs_27017/data/db
/usr/local/mongodb/bin/mongod --repair --
dbpath=/mongodb/replica_sets/myrs_27018/data/db
/usr/local/mongodb/bin/mongod --repair --
dbpath=/mongodb/replica_sets/myrs_27019/data/db

/usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27017/mongod.conf
/usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27018/mongod.conf
/usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27019/mongod.conf

在主节点上添加普通账号

#先用管理员账号登录
#切换到admin库
use admin
#管理员账号认证
db.auth("myroot","123456")
#切换到要认证的库
use articledb
#添加普通用户
db.createUser({user: "bobo", pwd: "123456", roles: ["readWrite"]})

重新连接，使用普通用户bobo重新登录，查看数据。

uri连接

mongodb://bobo:123456@180.76.159.126:27017,180.76.159.126:27018,180.76.159.126:27019/articledb?connect=replicaSet&slaveOk=true&replicaSet=myrs

分片集群环境

标准的关闭方法（可选）

关闭分片服务器副本集中的服务，建议依次关闭仲裁节点、副本节点、主节点。

//客户端登录服务，注意，这里通过localhost登录，如果需要远程登录，必须先登录认证才行。
mongo --port 27018
//告知副本集说本机要下线
rs.stepDown()
//#切换到admin库
use admin
//关闭服务
db.shutdownServer()

关闭配置服务器副本集的服务，建议依次关闭副本节点、主节点。主要的操作步骤参考如下：

//客户端登录服务，注意，这里通过localhost登录，如果需要远程登录，必须先登录认证才行。
mongo --port 27019
//告知副本集说本机要下线
rs.stepDown()
//#切换到admin库
use admin
//关闭服务
db.shutdownServer()

关闭路由服务器的服务，建议依次关闭两个路由节点。主要的操作步骤参考如下：

//客户端登录服务，注意，这里通过localhost登录，如果需要远程登录，必须先登录认证才行。
mongo --port 27017
//告知副本集说本机要下线
rs.stepDown()
//#切换到admin库
use admin
//关闭服务
db.shutdownServer()

创建副本集认证的key文件

第一步：生成一个key文件到当前文件夹中。

可以使用任何方法生成密钥文件。例如，以下操作使用openssl生成密码文件，然后使用chmod来更改
文件权限，仅为文件所有者提供读取权限

[root@bobohost ~]# openssl rand -base64 90 -out ./mongo.keyfile
[root@bobohost ~]# chmod 400 ./mongo.keyfile
[root@bobohost ~]# ll mongo.keyfile
-r--------. 1 root root 122 8月 14 14:23 mongo.keyfile

修改配置文件指定keyfile

对于副本集：

security:
	#KeyFile鉴权文件
	keyFile: /mongodb/sharded_cluster/myshardrs01_27018/mongo.keyfile
	#开启认证方式运行
	authorization: enabled

对于mongos：

security:
	#KeyFile鉴权文件
	keyFile: /mongodb/sharded_cluster/mymongos_27017/mongo.keyfile

mongos比mongod少了authorization：enabled的配置。原因是，副本集加分片的安全认证需要配置
两方面的，副本集各个节点之间使用内部身份验证，用于内部各个mongo实例的通信，只有相同keyfile
才能相互访问。所以都要开启 keyFile:/mongodb/sharded_cluster/mymongos_27117/mongo.keyfile 。

然而对于所有的mongod，才是真正的保存数据的分片。mongos只做路由，不保存数据。所以所有的
mongod开启访问数据的授权authorization:enabled。这样用户只有账号密码正确才能访问到数据。

重新启动节点

必须依次启动配置节点、分片节点、路由节点：

/usr/local/mongodb/bin/mongod -f
/mongodb/sharded_cluster/myconfigrs_27019/mongod.conf
/usr/local/mongodb/bin/mongod -f
/mongodb/sharded_cluster/myconfigrs_27119/mongod.conf
/usr/local/mongodb/bin/mongod -f
/mongodb/sharded_cluster/myconfigrs_27219/mongod.conf

/usr/local/mongodb/bin/mongod -f
/mongodb/sharded_cluster/myshardrs01_27018/mongod.conf
/usr/local/mongodb/bin/mongod -f
/mongodb/sharded_cluster/myshardrs01_27118/mongod.conf
/usr/local/mongodb/bin/mongod -f
/mongodb/sharded_cluster/myshardrs01_27218/mongod.conf

/usr/local/mongodb/bin/mongod -f
/mongodb/sharded_cluster/myshardrs02_27318/mongod.conf
/usr/local/mongodb/bin/mongod -f
/mongodb/sharded_cluster/myshardrs02_27418/mongod.conf
/usr/local/mongodb/bin/mongod -f
/mongodb/sharded_cluster/myshardrs02_27518/mongod.conf

/usr/local/mongodb/bin/mongos -f
/mongodb/sharded_cluster/mymongos_27017/mongos.conf
/usr/local/mongodb/bin/mongos -f
/mongodb/sharded_cluster/mymongos_27117/mongos.conf

这里有个非常特别的情况，就是启动顺序。先启动配置节点，再启动分片节点，最后启动路由节点。
如果先启动分片节点，会卡住，提示：

about to fork child process, waiting until server is ready for connections

创建帐号和认证

客户端mongo，通过localhost登录任意一个mongos路由，提示：相当于一个后门，只能在admin下添加用户。

/usr/local/mongodb/bin/mongo --port 27017

创建一个管理员帐号：

mongos> use admin
switched to db admin
mongos> db.createUser({user:"myroot",pwd:"123456",roles:["root"]})
Successfully added user: { "user" : "myroot", "roles" : [ "root" ] }

如果在开启认证之前已经创建了管理员账号，这里可以忽略。

创建一个普通权限帐号：

mongos> use admin
switched to db admin
mongos> db.auth("myroot","123456")
1
mongos> use articledb
switched to db articledb
mongos> db.createUser({user: "bobo", pwd: "123456", roles: [{ role: "readWrite",
db: "articledb" }]})

mongos> db.auth("bobo","123456")

通过mongos添加的账号信息，只会保存到配置节点的服务中，具体的数据节点不保存账号信息，因
此，分片中的账号信息不涉及到同步问题。

mongo客户端登录mongos路由，用管理员帐号登录可查看分片情况：

mongos> use admin
switched to db admin
mongos> db.auth("myroot","123456")
1
mongos> sh.status()

退出连接，重新连接服务，使用普通权限帐号访问数据：

[root@bobohost db]# /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port
27017
MongoDB shell version v4.0.10
connecting to: mongodb://180.76.159.126:27017/?gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("6f84fa91-2414-407e-b3ab-c0b7eedde825")
}
MongoDB server version: 4.0.10
mongos> use articledb
switched to db articledb
mongos> db.auth("bobo","123456")
1
mongos> show collections
comment
comment2
mongos> db.comment.count()
10001

uri登录

使用用户名和密码连接到 MongoDB 服务器，你必须使用
'username:password@hostname/dbname' 格式，'username'为用户名，‘password’ 为密码。

mongodb://bobo:123456@180.76.159.126:27017,180.76.159.126:27117/articledb
Generalzy
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 3
    评论
专栏目录
mongodb集群
m0_65931372的博客
06-23 7794
复制提供了数据的冗余备份，并在多个服务器上存储数据副本，提高了数据的可用性， 并保证数据的安全性。 主从复制集群 主从复制只有 1 个主节点，至少有 1 个从节点，可以有多个从节点。它们的身份是在启 MongoDB数据库服务时就需要指定的。所有的从节点都会自动地去主节点获取最新数据，做到主从节点数据保持一致。注意主节点是不会去从节点上读取数据的，只会输出数据到从节点。理论上 1 个集群中可以有无数个从节点，但是这么多的从节点对主节点进行访问，主节点会受不了。《MongoDB 权威指南》中有说不超过 12 个
MongoDB 集群
程序猿进阶
03-26 1463
负责接收所有客户端应用程序的连接查询请求，并将请求路由到集群内部对应的分片上，同时会把接收到的响应拼装起来返回到客户端。里大概存储了多少数据量等。我们说过，纵向优化是对硬件使用者最友好的，横向优化则对硬件使用者提出了更高的要求，也就是说软件架构要适配。就是用来量化可用性的协议，在双方认可的前提条件下，服务提供商与用户间定义的一种双方认可的协定。函数中，计算出一个整数值，值的集合形成了一个值域，我们按照固定步长去切分这个值域，每一个片叫做。架构在副本集的基础上，通过多组复制集群的组合，实现数据的横向扩展。
深入剖析MongoDB集群架构设计
最新发布
我是一名热爱编程和分享知识的技术作者，在金融和教育领域有多年的研发管理经验，感谢您访问我的博客，一定会为您带来不一样的收货！
04-14 1245
MongoDB 有三种集群架构模式，分别为主从复制（Master-Slaver）、副本集（Replica Set）和分片（Sharding）模式。当讨论 MongoDB 的集群架构时，应强调副本集和分片这两种官方推荐和支持的模式。如果在历史背景下讨论，可以提及主从复制作为早期的一种复制方式，但需明确指出它在现代 MongoDB 中已不再适用。探索非关系型世界：MongoDB核心概念全解析-CSDN博客TiDB存储引擎TiKV揭秘-CSDN博客。
MongoDB的原理、基本使用、集群和分片集群
好好学习，天天向上！
04-09 2239
文章目录一、MongoDB的核心概念二、MongoDB的应用场景三、MongoDB的项目落地四、MongoDB的运行原理五、MongoDB的 CURD操作六、MongoDB项目封装七、MongoDB的索引八、MongoDB的分片九、MongoDB的集群 一、MongoDB的核心概念 概念 MongoDB是文档数据库，存储都是类似json的Bosn文件。 json与Bosn区别 相同点 格式一摸一样。 不同点 json无法定义数据类型。Bosn可以定义具体的数据类型。 MongoDB与传统数据库的
MongoDB 的集群架构与设计
架构师小秘圈
11-29 224
一、前言MongoDB 有三种集群架构模式，分别为主从复制（Master-Slaver）、副本集（Replica Set）和分片（Sharding）模式。Master-Slaver 是一种主从复制的模式，目前已经不推荐使用。Replica Set 模式取代了 Master-Slaver 模式，是一种互为主从的关系。Replica Set 将数据复制多份保存，不同服务器保存同一份数据，在出现故障时自...
【超详细】手把手教你搭建MongoDB集群搭建
博学谷狂野架构师的博客
07-14 1万+
​ 为解决mongodb在replica set每个从节点上面的数据库均是对数据库的全量拷贝，从节点压力在高并发大数据量的场景下存在很大挑战，同时考虑到后期mongodb集群的在数据压力巨大时的扩展性，应对海量数据引出了分片机制。​ 分片是将数据库进行拆分，将其分散在不同的机器上的过程，无需功能强大的服务器就可以存储更多的数据，处理更大的负载，在总数据中，将集合切成小块，将这些块分散到若干片中，每个片只负载总数据的一部分，通过一个知道数据与分片对应关系的组件mongos的路由进程进行操作。​ 数据库集
MongoDB集群配置
06-13
对MongoDB的集配配置及分片集群配置,对集群故障转移和选举规则的配置,MongDb的安全认证,SpringDataMong链接认证
mongoDB集群
08-07
mongoDB集群搭建分片+副本集,安装搭建笔记，包括集权安全配置
mongodb分片集群增加acl
03-15
mongodb集群分片操作以及增加acl，有什么问题联系我！
MongoDB集群部署&开启身份认证部署包
06-16
简单打包分布式部署MongoDB集群，开启身份认证发布工具包示例。 使用参考博客地址 https://blog.csdn.net/csdn710924032/article/details/80713877 内附度盘
mongodb副本集加分片集群安全认证使用账号密码登录
08-23
mongodb副本集加分片集群安全认证使用账号密码登录
mongodb复制集集群部署、测试、选举原理
youcan_doit的博客
07-04 1289
mongodb复制集集群部署、测试、选举原理
MongoDB集群模式详解及应用实战
yemuxiaweiliang的博客
11-29 2339
MongoDB集群模式详解及应用实战
玩转MongoDB—搭建MongoDB集群
做兴趣使然的Hero
07-01 2128
如题，本次玩转MongoDB我们从搭建集群开始，话说MongoDB一共有三种搭建集群的方式，但是由于版本更新，据说在4.0版本之后第一种方式，也就是主从复制的方式被遗弃掉了，大概是因为这种方式的效率不高吧，因为目前我们使用的是5.x版本，因此就不花时间讲解第一种方式了，在其他的文章上摘录了一下，可供大家参考。...
MongoDB集群搭建（四）
沉浸式Study
06-26 1073
因为由多个容器，配置文件是一样的，只需要创建一个配置文件，其他的容器统一读取该配置文件即可,因为Mongos只负责路由，就不需要数据文件了，并且mongos服务是不负责认证的，需要将。因为有多个容器，配置文件是一样的，只需要创建一个配置文件，其他的容器统一读取该配置文件即可。因为有多个容器，配置文件是一样的，只需要创建一个配置文件，其他的容器统一读取该配置文件即可。因为由多个容器，配置文件是一样的，只需要创建一个配置文件，其他的容器统一读取该配置文件即可。是无中心的配置，所有需要每一台都需要进行分片配置。
MongoDB分片集群(sharded cluster)搭建过程
热门推荐
duanbeibei的专栏
04-16 1万+
1.分片集群概述 MongoDB分片集群，英文名称为： Sharded Cluster 旨在通过横向扩展，来提高数据吞吐性能、增大数据存储量。 分片集群由三个组件：“mongos”, “config server”, “shard” 组成。 框架如下（图片来自mongodb官网说明）： mongos:数据库请求路由。负责接收所有客户端应用程序的连接查询请求，并将请求路由到集群内部对应的分片上。...
2. MongoDB分片集群架构实战-----MongoDB分片集群和多文档事务详解
俺就是菜的很的博客
06-28 2158
分片(shard)是指在将数据进行水平切分之后，将其存储到多个不同的服务器节点上的一种扩展方式。分片在概念上非常类似于应用开发中的“水平分表"。不同的点在于，MongoDB本身就自带了分片管理的能力，对于开发者来说可以做到开箱即用。为什么要使用分片?MongoDB复制集实现了数据的多副本复制及高可用，但是一个复制集能承载的容量和负载是有限的。在你遇到下面的场景时，就需要考虑使用分片了∶存储容量需求超出单机的磁盘容量。活跃的数据集超出单机内存容量,导致很多请求都要从磁盘读取数据，影响性能。
MongoDB集群管理（三）
沉浸式Study
06-25 1433
随着业务数据和并发量的增加，若只使用一台MongoDB服务器，存在着断电和数据风险的问题，故采用Mongodb复制集的方式，来提高项目的高可用、安全性等性能。MongoDB复制是将数据同步到多个服务器的过程。复制提供了数据的冗余备份，并在多个服务器上存储数据副本，提高了数据的可用性， 并可以保证数据的安全性。复制还允许从硬件故障和服务中断中恢复数据。使用集群的目的就是提高可用性。
8.MongoDB之分片集群
mijichui2153的博客
03-14 1万+
一、mongodb分片与各角色与概念介绍 Mongodb的分片机制是mongodb数据库的核心机制，也是其可用性高，扩展性好的原因，分片—sharding 的意思就是将数据库数据分散存贮到不同的服务器上，来缓解高并发访问，均衡负载。举例来说一下，比如说一个collection有TB级别的数据，在传统方式下如果有两个线程要访问其中的数据，即使这个线程访问的数据是不同的，为保证同步需要排队等待，分片机制可以很好的解决这个问题，分片机制其实就是分布式的集群，比如现在有五台服务器作为集群，mongodb可以将一.
mongodb集群部署
07-08
对于MongoDB集群部署，您可以按照以下步骤进行操作： 1. 安装MongoDB：在每个节点上安装MongoDB数据库，并确保所有节点上的版本一致。 2. 配置节点：为每个节点创建一个配置文件，其中包括节点的唯一标识符、IP地址、端口号等信息。您可以使用MongoDB的配置文件模板作为起点，并根据需要进行修改。 3. 启动节点：在每个节点上启动MongoDB实例。您可以使用命令行工具或配置文件来启动实例。确保每个节点的配置文件中指定了正确的节点角色（如Primary、Secondary或Arbiter）。 4. 设置复制集：在主节点上初始化复制集，并将所有其他节点添加为成员。通过运行命令`rs.initiate()`可以初始化复制集，然后使用`rs.add()`命令将其他节点添加到复制集中。 5. 配置Sharding：如果您计划使用MongoDB的分片功能，您需要设置和配置分片。这涉及到定义分片键、创建分片集合和启动分片服务等步骤。 6. 监控和管理：为了确保集群的正常运行，您可以使用MongoDB提供的工具来监控和管理集群。例如，MongoDB提供了MongoDB Ops Manager和MongoDB Cloud Manager等工具来帮助您监控性能、备份数据、进行故障恢复等操作。 这些是MongoDB集群部署的一般步骤，具体操作可能会因环境和需求而有所不同。在进行部署之前，请确保您已经详细了解了MongoDB集群的架构和配置要求，并采取适当的安全措施来保护您的数据。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Generalzy

倍感荣幸文章对您有帮助

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值