mongodb sharded cluster中的概念

本文介绍了MongoDB分片集群的组成部分,包括shared、mongos和configservers,并详细阐述了分片数据如何均衡分布,分片键的作用,以及hash分片和范围分片的策略。此外还探讨了分片集群的限制、部署考虑因素、维护操作和查询路由过程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

mongodb的分片集群包含下面的几部分:
shared:每个shared包含一系列的分片数据,每个shared可以部署为单个的replica set
mongos:这个是个查询路由,在客户端和集群间提供接口,处理应用层的查询请求,决定数据在集群中的位置。
config servers:配置server,存放了元数据和集群的配置信息,3.2版本中,配置server可以部署为一个replica set
拓扑图的连接:
https://docs.mongodb.com/manual/sharding/

mongodb分片数据是在集合级别分片的,将集合的数据均衡分布在集群中。
为了在集合中分片,mongodb使用分片键,是在目标集合中的document中存在的字段组成。
分片的集合只能有1个分片键。对于非空的集合,集合必须有一个已分片键开始的索引,对于空的集合,mongodb会创建一个索引。
mongodb将分片的数据放入chunks中,每个chunk包含一个以分片键划分排他的最小值,最大值范围。mongo使用shared cluster balancer来将chunks在集群中进行平衡的迁移。

对于不包含分片键或包含分片键的组合查询,mongos不是路由,而是进行广播操作,会查询集群中的所有的分片。
一个数据库可以混合分片和非分片集合,分片的集合把分区分散在集群中的分片上,对于非分片的集合会存放在主分片上,每一个数据库都有他自己的主分片。

连接到一个分片集群上的方式就是连接mongos
mongodb有2个分片的策略
hash分片
这个对于键值不经常改变,没有很多范围查询的情况下比较有用。
范围分片
就是按照分片键来进行范围分片,需要注意的就是分区键的选择,需要让数据尽可能的均衡。

分片集群的一些限制:
一些操作不能使用
https://docs.mongodb.com/manual/core/sharded-cluster-requirements/#sharding-operational-restrictions

线上部署的考虑:
将配置server配置成1个包含3个成员的replica set
对每个shard配置成包含3个成员的replica set
部署一个或多个mongos路由器。
分片至少需要2个shard来分散分片数据,选择primary shard是通过选择一个数据量最小的shard。

查看shard状态:
sh.status()
配置server不能共享,只能单独使用,每个分片集群有自己的配置server.

配置server如果使用replica set的模式,那么必须要使用WiredTiger 存储引擎。
有下面的一些限制:
不能有arbiters,不能有部署的成员。
必须构建索引。
mongos中会缓存配置信息,所以如果配置server不可用了,只要没有重启mongos,那么是可以继续使用的。配置server包含了元数据,元数据反应了在分片集群中的各个组件的状态和组织情况,包含了在每个分片上的chunk列表,及chunk的范围。只会在下面的几种情况下写数据到配置server,
1chunk迁移2chunk分裂

如果配置server replica set丢失了主,不能选举主,那么集群的元数据是只读的,你可以继续在分片中读取和写入数据,但是不能进行chunk迁移和分裂。配置server都坏了,那集群可能会不可用了。
配置信息存储在了配置数据库,要访问配置数据库,使用
use config
正常情况下,是不应该编辑config数据库的。
对于转发server
The mongos then merges the data from each of the targeted shards and returns the result document. Certain query modifiers, such as sorting, are performed on a shard such as the primary shard before mongos retrieves the results.
对于一些查询描述符的处理:
https://docs.mongodb.com/manual/core/sharded-cluster-query-router/
要分片一个集合,需要使用下面的方法:
sh.shardCollection( namespace, key )

默认的chunk大小是64m,可以修改chunk的大小,小的chunk的就是能让数据更均衡分布,但是在mongos层转发会耗费时间。大的chunk导致更少的迁移,在内部负载和路由层的负载较低,但是数据可能会不均衡。

自动分裂只是在插入或更新的时候发生,但是你减少了chunk的大小,可能会让所有的chunk分裂。分裂的操作不是可回撤的,如果增大了chunk的大小,那么已存在的chunk的大小直到增加到新的大小才会分裂。
分裂chunk是为了防止chunk太大,当达到了指定的chunk大小,或是chunk上的文档数量超过了 Maximum Number of Documents Per Chunk to Migrate,mongodb会基于分片键来分裂,分裂可能导致集合的chunk分布不平衡,在这种情况下,mongos会初始化一个迁移来让chunk重新分布在分片上。
chunk的迁移:
手工迁移
自动迁移:当集合的chunk分布不均衡的时候,balancer进程自动迁移

如果最大分片和最小分片的差距超过了migration thresholds的时候,balancer开始迁移。
在一些情况下,chunk是不能分裂的,可以超过指定的大小,通常是一个chunk代表了一个单分片键的值。
在mongodb2.6开始,sharding.archiveMovedChunks默认情况下是被启用的,原始的数据被保存在了storage.dbPath下的moveChunk目录下。
如果在迁移的过程中发生了错误,这些文件可以用来恢复,在迁移完成后,如果没有文件损坏,可以删除这些文件,可见这部分随着时间慢慢会越来越大,需要注意,可以通过查看sh.isBalancerRunning()来看所有的迁移任务十分已经完成。使用sh.status()来查看集群中的chunk分布。手工分片的命令:https://docs.mongodb.com/manual/tutorial/split-chunks-in-sharded-cluster/

修改chunk的大小:
1通过mongo连接mongos
2切换到config库
use config
3db.settings.save( { _id:”chunksize”, value: } )

对于balancer,可以禁用或者是设置窗口,来减小对线上环境的影响。
chunk迁移的过程:
https://docs.mongodb.com/manual/core/sharding-balancer-administration/
查看balancer状态:sh.status()
查看balancer是否激活:
use config
db.locks.find( { _id : “balancer” } ).pretty()

查看集群中的所有数据库:
use config
db.databases.find( { “partitioned”: true } )或db.databases.find()

列出当前分片信息:
use admin
db.runCommand( { listShards : 1 } )

sh.status()

<think>好的,我现在需要详细解释用户提到的Mongoose监听表数据变化的三个依赖条件:MongoDB版本≥3.6、配置为副本集或分片集群、用户具备changeStream权限。首先,我得确保自己对这些条件有深入的理解,以便准确传达给用户。 首先,MongoDB版本≥3.6。我记得Change Streams是在MongoDB 3.6版本引入的,所以如果用户使用的是旧版本,这个功能不可用。需要确认用户是否了解如何检查他们的MongoDB版本,可能还需要指导他们如何升级,但用户的问题可能只需要解释为什么需要这个版本,不需要操作步骤。 接下来,配置为副本集或分片集群。这是因为Change Streams依赖于oplog(操作日志),而oplog只在副本集或分片集群中可用。独立模式(standalone)的MongoDB没有oplog,所以无法使用Change Streams。用户可能不清楚副本集的基本配置,是否需要简单解释副本集是什么?或者他们可能已经了解,但需要强调配置的重要性。另外,分片集群的情况可能更复杂,但用户可能更常用副本集,所以可以侧重解释副本集。 第三个条件是用户需要具备changeStream权限。MongoDB的权限控制中,changeStream权限允许用户监听数据变化。可能需要说明如何创建具有该权限的用户,比如通过db.createUser命令,并分配适当的角色,比如readWrite权限加上对local数据库oplog.rs的读取权限。用户可能在实际操作中遇到权限问题,比如没有正确配置角色导致监听失败,所以需要明确权限设置步骤。 然后,我需要考虑如何组织这些信息,使其结构清晰。可能需要分点解释每个条件的原因和相关注意事项。例如,每个条件作为一个子标题,下面详细说明原因、影响和可能的解决方法。同时,需要提供示例或代码片段,比如创建用户的Mongo Shell命令,帮助用户理解如何实际操作。 另外,用户可能想知道如果不符合这些条件怎么办,比如他们使用的是独立模式的MongoDB,是否有替代方案?这时候可能需要提到其他方法,如定时轮询或Mongoose中间件,但明确说明这些方法的局限性,比如实时性差或仅捕获通过Mongoose的操作。 还需要注意技术术语的解释,比如oplog、副本集、分片集群等,可能需要用简单的语言让用户理解这些概念,尤其是如果用户是初学者的话。但用户的问题可能已经有一定了解,所以解释需要简洁,不过于冗长。 最后,确保回答准确,避免错误。比如,确认changeStream权限的具体角色,可能需要查阅MongoDB文档确认是否正确。例如,是否真的需要local数据库oplog.rs的读取权限,或者是否有其他方式配置。这可能涉及权限配置的最佳实践,避免给予不必要的权限,确保安全性。 总结来说,回答需要分三个部分,每个依赖条件单独解释,说明原因、如何满足以及相关注意事项。同时,可能需要提供配置示例和替代方案的对比,帮助用户全面理解。</think>### **Mongoose 监听数据变化的依赖条件详解** --- #### **1. MongoDB ≥ 3.6** - **原因** Change Streams(变更流)功能从 MongoDB 3.6 版本开始支持,它是实现实时数据监听的核心机制。 - **如何验证版本** 在 MongoDB Shell 中执行: ```javascript db.version() ``` - **升级建议** 若版本低于 3.6,需升级 MongoDB 至 3.6 或更高版本(官方推荐生产环境使用最新稳定版)。 --- #### **2. 配置为副本集或分片集群** - **为什么需要副本集/分片集群** Change Streams 依赖 MongoDB 的 **操作日志(Oplog)** 实现数据变更追踪,而 Oplog 仅在副本集或分片集群中启用。 - **副本集(Replica Set)**:由至少 3 个节点组成(1 主节点 + 2 从节点),提供高可用性和数据冗余。 - **分片集群(Sharded Cluster)**:用于横向扩展大规模数据集,每个分片本身需为副本集。 - **独立模式(Standalone)的限制** 单机运行的 MongoDB 无 Oplog,无法使用 Change Streams。需转换为副本集模式: ```bash # 关闭现有 MongoDB 服务 mongod --shutdown # 以副本集模式启动(单节点测试用) mongod --replSet rs0 --port 27017 ``` ```javascript // 在 MongoDB Shell 初始化副本集 rs.initiate() ``` --- #### **3. 用户需具备 `changeStream` 权限** - **权限要求** 用户需拥有以下权限: 1. 对目标数据库的 `readWrite` 权限(或更高级别)。 2. 对 `local` 数据库的 `oplog.rs` 集合的 `find` 权限(Change Streams 依赖 Oplog 读取变更记录)。 - **配置用户权限示例** 在 MongoDB Shell 中执行: ```javascript use admin db.createUser({ user: "my_user", pwd: "secure_password", roles: [ { role: "readWrite", db: "my_database" }, // 业务数据库权限 { role: "read", db: "local", collection: "oplog.rs" } // Oplog 读取权限 ] }) ``` --- ### **常见问题与解决方案** 1. **错误 `Change streams require replica sets`** **原因**:MongoDB 未以副本集模式运行。 **解决**:按上述步骤配置副本集。 2. **错误 `user not allowed to do action [find] on [local.oplog.rs]`** **原因**:用户缺少 Oplog 读取权限。 **解决**:为用户添加 `local.oplog.rs` 的 `find` 权限。 3. **独立模式无法使用 Change Streams** **替代方案**: - 改用定时轮询查询(牺牲实时性)。 - 使用 Mongoose Middleware(仅捕获通过 Mongoose 的操作)。 --- ### **总结** | **依赖条件** | **核心目的** | **不满足的后果** | |-----------------------|---------------------------------|----------------------------------| | MongoDB ≥ 3.6 | 启用 Change Streams 功能 | 监听功能完全不可用 | | 副本集/分片集群 | 提供 Oplog 支持变更追踪 | 无法捕获数据变化事件 | | `changeStream` 权限 | 授权用户访问 Oplog 和业务数据 | 监听请求被 MongoDB 拒绝 | 通过正确配置上述条件,即可利用 Mongoose 高效监听数据变更,构建实时响应应用。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值