数据库

MongoDB的分片集群基本配置教程
数据库 2024/11/5 佚名
3 2

为何要分片
1.减少单机请求数，降低单机负载，提高总负载
2.减少单机的存储空间，提高总存空间。

MongoDB的分片集群基本配置教程

常见的mongodb sharding 服务器架构

MongoDB的分片集群基本配置教程

要构建一个 MongoDB Sharding Cluster，需要三种角色：
1.Shard Server
即存储实际数据的分片，每个Shard可以是一个mongod实例，也可以是一组mongod实例构成的Replication Set。为了实现每个Shard内部的auto-failover(自动故障切换)，MongoDB官方建议每个Shard为一组Replica Set。
2.Config Server
为了将一个特定的collection存储在多个shard中，需要为该collection指定一个shard key(片键)，例如{age: 1} ，shard key可以决定该条记录属于哪个chunk(分片是以chunk为单位,后续会介绍)。Config Servers就是用来存储：所有shard节点的配置信息、每个chunk的shard key范围、chunk在各shard的分布情况、该集群中所有DB和collection的sharding配置信息。
3.Route Process
这是一个前端路由，客户端由此接入，然后询问Config Servers需要到哪个Shard上查询或保存记录，再连接相应的Shard进行操作，最后将结果返回给客户端。客户端只需要将原本发给mongod的查询或更新请求原封不动地发给Routing Process，而不必关心所操作的记录存储在哪个Shard上。（所有操作在mongos上操作即可）

配置分片服务器
下面我们在同一台物理机器上构建一个简单的 Sharding Cluster：

MongoDB的分片集群基本配置教程

Shard Server 1：27017
Shard Server 2：27018
Config Server ：27027
Route Process：40000

1.步骤一: 启动Shard Server

mkdir -p ./data/shard/s0 ./data/shard/s1 #创建数据目录
mkdir -p ./data/shard/log # 创建日志目录
./bin/mongod --port 27017 --dbpath /usr/local/mongodb/data/shard/s0 --fork --logpath /usr/local/mongodb/data/shard/log/s0.log # 启动Shard Server实例1
./bin/mongod --port 27018 --dbpath /usr/local/mongodb/data/shard/s1 --fork --logpath /usr/local/mongodb/data/shard/log/s1.log # 启动Shard Server实例2

步2.骤二: 启动Config Server

mkdir -p ./data/shard/config #创建数据目录
./bin/mongod --port 27027 --dbpath /usr/local/mongodb/data/shard/config --fork --logpath /usr/local/mongodb/data/shard/log/config.log #启动Config Server实例

注意，这里我们完全可以像启动普通mongodb服务一样启动，不需要添加—shardsvr和configsvr参数。因为这两个参数的作用就是改变启动端口的，所以我们自行指定了端口就可以
3.步骤三: 启动Route Process
./bin/mongos --port 4000 --configdb localhost:27027 --fork --logpath /usr/local/mongodb/data/shard/log/route.log --chunkSize=1 # 启动Route Server实例
mongos启动参数中，chunkSize这一项是用来指定chunk的大小的，单位是MB，默认大小为200MB，为了方便测试Sharding效果，我们把chunkSize指定为 1MB。意思是当这个分片中插入的数据大于1M时开始进行数据转移
4.步骤四: 配置Sharding

# 我们使用MongoDB Shell登录到mongos，添加Shard节点
./bin/mongo admin --port 40000 #此操作需要连接admin库
> db.runCommand({ addshard:"localhost:27017" }) #添加 Shard Server 或者用 sh.addshard()命令来添加,下同;
{ "shardAdded" : "shard0000", "ok" : 1 }
> db.runCommand({ addshard:"localhost:27018" })
{ "shardAdded" : "shard0001", "ok" : 1 }
> db.runCommand({ enablesharding:"test" }) #设置分片存储的数据库
{ "ok" : 1 }
> db.runCommand({ shardcollection: "test.users", key: { id:1 }}) # 设置分片的集合名称。且必须指定Shard Key，系统会自动创建索引，然后根据这个shard Key来计算
{ "collectionsharded" : "test.users", "ok" : 1 }
 > sh.status(); #查看片的状态
 > printShardingStatus(db.getSisterDB("config"),1); # 查看片状态(完整版);
 > db.stats(); # 查看所有的分片服务器状态

注意这里我们要注意片键的选择，选择片键时需要根据具体业务的数据形态来选择，切不可随意选择，实际中尤其不要轻易选择自增_id作为片键，除非你很清楚你这么做的目的，具体原因我不在此分析，根据经验推荐一种较合理的片键方式，“自增字段+查询字段”，没错，片键可以是多个字段的组合。
另外这里说明一点，分片的机制：mongodb不是从单篇文档的级别,绝对平均的散落在各个片上, 而是N篇文档,形成一个块"chunk",优先放在某个片上, 当这片上的chunk,比另一个片的chunk区别比较大时(>=3) ,会把本片上的chunk,移到另一个片上, 以chunk为单位,维护片之间的数据均衡。
也就是说，一开始插入数据时，数据是只插入到其中一块分片上的，插入完毕后，mongodb内部开始在各片之间进行数据的移动，这个过程可能不是立即的，mongodb足够智能会根据当前负载决定是立即进行移动还是稍后移动。
在插入数据后，立马执行db.users.stats();两次可以验证如上所说。
这种分片机制,节省了人工维护成本,但是由于其是优先往某个片上插入,等到chunk失衡时,再移动chunk,并且随着数据的增多,shard的实例之间,有chunk来回移动的现象,这将会为服务器带来很大的IO开销,解决这种开销的方法,就是手动预先分片;

手动预先分片
以shop.user表为例：

sh.shardCollection(‘shop.user',{userid:1}); # user表用userid做shard key
for(var i=1;i<=40;i++) { sh.splitAt('shop.user',{userid:i*1000}) } # 预先在1K 2K...40K这样的界限切好chunk(虽然chunk是空的), 这些chunk将会均匀移动到各片上.
通过mongos添加user数据. 数据会添加到预先分配好的chunk上, chunk就不会来回移动了.

repliction set and shard
一般mongoDB如果真的到了分片的级别后,那片服务器避无可免的要用到复制集,部署的基本思路同上,只需要注意两点:
sh.addShard( host ) server:port OR setname/server:port # 如果是复制集的片服务器,我们应该复制集的名称写在前面比如
sh.addShard('ras/192.168.42.168:27017'); # 27017也就是复制集中的primary
另外在启动本机的mongod服务的时候,最好把ip也给写进去,否则有可能会有不可预知的错误。

查看分片配置的方法：

1.列举使用分片的数据库
为了列举使用分片的数据库，需要查询Config数据库。如果partitioned域值为true，则这个库使用了分片技术。
连接一个mongos实例，运行命令获取使用分片功能的数据库：

use config
db.databases.find( { "partitioned" : true} )

例如：使用以下命令返回集群中的所有数据库

use config
db.databases.find()

如果返回结果：

{ "_id" : "admin", "partitioned" : false, "primary" : "config" }
{ "_id" : "mydb", "partitioned" : true, "primary" : "firstset" }
{ "_id" : "test", "partitioned" : false, "primary" : "secondset" }

显示只有mydb使用了分片。

2.列举所有的分片
为了列举当前集合的所有分片，使用listShards命令：

use admin
db.runCommand( { listShards : 1 })

返回结果：

{
    "shards" : [
        {
            "_id" : "firstset",
            "host" : "firstset/mongo01:10001,mongo01:10002,mongo01:10003"
        },
        {
            "_id" : "secondset",
            "host" : "secondset/mongo01:30001,mongo01:30002,mongo01:30003"
        }
    ],
    "ok" : 1
}

3.查看集群的详细信息
为了查看集群的详细信息，可以使用db.printShardingStatus()或者sh.status()。所有的方法返回同样的结果。
例如，使用

sh.status()

查看信息：

--- Sharding Status --- 
 sharding version: {
    "_id" : 1,
    "version" : 4,
    "minCompatibleVersion" : 4,
    "currentVersion" : 5,
    "clusterId" : ObjectId("535a2dab0063b308757e1b70")
}
 shards:
    { "_id" : "firstset", "host" : "firstset/mongo01:10001,mongo01:10002,mongo01:10003" }
    { "_id" : "secondset", "host" : "secondset/mongo01:30001,mongo01:30002,mongo01:30003" }
 databases:
    { "_id" : "admin", "partitioned" : false, "primary" : "config" }
    { "_id" : "mydb", "partitioned" : true, "primary" : "firstset" }
        mydb.test_collection
            shard key: { "name" : 1 }
            chunks:
                secondset    6
                firstset    6
            { "name" : { "$minKey" : 1 } } -- { "name" : "cat" } on : secondset Timestamp(2, 0) 
            { "name" : "cat" } -- { "name" : "cow" } on : secondset Timestamp(3, 0) 
            { "name" : "cow" } -- { "name" : "dog" } on : secondset Timestamp(4, 0) 
            { "name" : "dog" } -- { "name" : "dragon" } on : secondset Timestamp(5, 0) 
            { "name" : "dragon" } -- { "name" : "elephant" } on : secondset Timestamp(6, 0) 
            { "name" : "elephant" } -- { "name" : "horse" } on : secondset Timestamp(7, 0) 
            { "name" : "horse" } -- { "name" : "lion" } on : firstset Timestamp(7, 1) 
            { "name" : "lion" } -- { "name" : "pig" } on : firstset Timestamp(1, 7) 
            { "name" : "pig" } -- { "name" : "rabbit" } on : firstset Timestamp(1, 8) 
            { "name" : "rabbit" } -- { "name" : "snake" } on : firstset Timestamp(1, 9) 
            { "name" : "snake" } -- { "name" : "tiger" } on : firstset Timestamp(1, 10) 
            { "name" : "tiger" } -- { "name" : { "$maxKey" : 1 } } on : firstset Timestamp(1, 11) 
    { "_id" : "test", "partitioned" : false, "primary" : "secondset" }

（1）sharding version展示了分片元数据的版本号。
（2）shards展示了在集群中被作为分片的mongod实例。
（3）databases展示了集群中所有的数据库，包括没有使用分片功能的库。
（4）chunks信息展示了mydb库的每个分片上有多少个块和每个块的范围。

标签：
MongoDB,分片集群,分片
免责声明：本站文章均来自网站采集或用户投稿，网站不提供任何软件下载或自行开发的软件！ 如有用户或公司发现本站内容信息存在侵权行为，请邮件告知！ 858582#qq.com
白云城资源网 Copyright www.dyhadc.com

评论“MongoDB的分片集群基本配置教程”

暂无“MongoDB的分片集群基本配置教程”评论...
www.dyhadc.com 白云城资源网
129,905影音资源
244,626技术资源
111,817软件资源
578,645站长资源
一句话新闻
一口气升级7个大模型SaaS应用，百度智能云：突出一个“开箱即用” - 2024/11/5

这一波大模型产业落地浪潮里，不少企业其实处在 “干瞪眼“的状态。

一种情况是，很多大模型产品看得见却摸不着，在台上一个个遥遥领先——今天Sora技精四座，明天英伟达的机器人又赢得满堂彩，可是到了台下一问：啥时候能用上啊？答曰：遥遥无期。

另一种情况是，企业想用上大模型，却又难免瞻前顾后——既要考虑场景融合，又得兼顾安全性，还要考虑打通现有系统，再加上各种部署成本和繁琐的采购流程……最后只能拂袖：罢了，再等等吧。

稳了！魔兽国服回归的3条重磅消息！官宣时间再确认！

昨天有一位朋友在大神群里分享，自己亚服账号被封号之后居然弹出了国服的封号信息对话框。

这里面让他访问的是一个国服的战网网址，com.cn和后面的zh都非常明白地表明这就是国服战网。

而他在复制这个网址并且进行登录之后，确实是网易的网址，也就是我们熟悉的停服之后国服发布的暴雪游戏产品运营到期开放退款的说明。这是一件比较奇怪的事情，因为以前都没有出现这样的情况，现在突然提示跳转到国服战网的网址，是不是说明了简体中文客户端已经开始进行更新了呢？

更新日志

友情链接

杰晶网络 DDR爱好者之家 南强小屋 黑松山资源网 白云城资源网 更多链接
白云城资源网 Copyright www.dyhadc.com