Shulou(Shulou.com)06/01 Report--

Operating system: CentOS 6 x86x64

MongoDB version: 3.4.3

Cluster host topology:

Host mongo shardsvr & ReplSetName

Mongo configsvr & ReplSetNamemongostest1.lanshard-a shard-b

Test2.lanshard-a shard-b

Test3.lanshard-a shard-b

Test4.lan

Cfgshard

Test5.lan

Cfgshard

Test6.lan

Cfgshard

Test7.lan

Yes

Test1-3 starts two mongod instances with different replica set names on one host.

The three hosts of test4-6 run separately as config server.

The test7 host acts as the mongos routing host.

Install MongoDB

Configure repo Feed

[mongodb-org-3.4] name=MongoDB Repository#baseurl= https://repo.mongodb.org/yum/redhat//mongodb-org/3.4/x86_64/baseurl=https://mirrors.aliyun.com/mongodb/yum/redhat/$releasever/mongodb-org/3.4/x86_64/gpgcheck=0enabled=1gpgkey=https://www.mongodb.org/static/pgp/server-3.4.asc

Select the domestic Aliyun image resource.

# yum install mongodb-org-y

Configuration / etc/mongod.conf

# mongod.conf# for documentation of all options See:# http://docs.mongodb.org/manual/reference/configuration-options/# where to write logging data.systemLog: destination: file logAppend: true path: / var/log/mongodb/mongod.log# Where and how to store data.storage: dbPath: / var/lib/mongo journal: enabled: true# engine:# mmapv1:# wiredTiger:# how the process runsprocessManagement: fork: true# fork and run in background pidFilePath: / var/run/mongodb/mongod.pid # location of pidfile# network interfacesnet: port: 27017 bindIp: 0.0.0.0 # Listen to local interface only Comment to listen on all interfaces.#security:#operationProfiling:replication: replSetName: shard-a sharding: clusterRole: shardsvr## Enterprise-Only Options#auditLog:#snmp:

The set name of the configuration copy at replication, and sharding enables shardsvr mode.

Start the mongod service

[root@test1 ~] # service mongod startStarting mongod: [OK] [root@test2 ~] # service mongod startStarting mongod: [OK] [root@test3 ~] # service mongod startStarting mongod: [OK]

Configure shard-a replica set

[root@test1] # mongo test1.lan:27017MongoDB shell version v3.4.3connecting to: test1.lan:27017MongoDB server version: 3.4.3Server has startup warnings: 2017-04-24T22:46:19.703+0800 I STORAGE [initandlisten] 2017-04-24T22:46:19.703+0800 I STORAGE [initandlisten] * * WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine2017-04-24T22:46:19.703+0800 I STORAGE [initandlisten] * * See http://dochub .mongodb.org/core/prodnotes-filesystem2017-04-24T22:46:20.321+0800 I CONTROL [initandlisten] > rs.initiate () {"info2": "no configuration specified. Using a default configuration for the set "," me ":" test1.lan:27017 "," ok ": 1} shard-a:SECONDARY > shard-a:PRIMARY > config = rs.config () # Save configuration object {" _ id ":" shard-a "," version ": 1," protocolVersion ": NumberLong (1) "members": [{"_ id": 0, "host": "test1.lan: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": 2000, "getLastErrorModes": {} "getLastErrorDefaults": {"w": 1, "wtimeout": 0}, "replicaSetId": ObjectId ("58fe111823612a418eb7f3fc")}} shard-a:PRIMARY > config.members [0] .priority = 2 # here increase the priority of your host to 2 Prevent subsequent PRIMARY re-election to the remaining hosts 2shard-a:PRIMARY > rs.reconfig (config) # reapply the configuration {"ok": 1} shard-a:PRIMARY > rs.add ("test2.lan:27017") # add replica set host {"ok": 1} shard-a:PRIMARY > rs.add ("test3.lan") # add Add replica set host (default port is 27017) {"ok": 1} shard-a:PRIMARY > rs.config () {"_ id": "shard-a" "version": 4, "protocolVersion": NumberLong (1), "members": [{"_ id": 0, "host": "test1.lan:27017", "arbiterOnly": false, "buildIndexes": true "hidden": false, "priority": 2, "tags": {}, "slaveDelay": NumberLong (0) "votes": 1}, {"_ id": 1, "host": "test2.lan:27017", "arbiterOnly": false, "buildIndexes": true "hidden": false, "priority": 1, "tags": {}, "slaveDelay": NumberLong (0) "votes": 1}, {"_ id": 2, "host": "test3.lan: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": 2000 "getLastErrorModes": {}, "getLastErrorDefaults": {"w": 1, "wtimeout": 0}, "replicaSetId": ObjectId ("58fe111823612a418eb7f3fc")}}

In this way, the replica set shard-an is configured

Next we start and configure the replica set shard-b

[root@test1] # mkdir / var/lib/mongo2 [root@test1 ~] # mongod-- shardsvr-- replSet shard-b-- dbpath / var/lib/mongo2/-- port 37017-- logpath / var/log/mongodb/mongod2.log-- fork-- journalabout to fork child process, waiting until server is ready for connections.forked process: 14323child process started successfully Parent exiting [root@test2] # mkdir / var/lib/mongo2 [root@test2] # mongod-- shardsvr-- replSet shard-b-- dbpath / var/lib/mongo2/-- port 37017-- logpath / var/log/mongodb/mongod2.log-- fork-- journalabout to fork child process, waiting until server is ready for connections.forked process: 5623child process started successfully Parent exiting [root@test3] # mkdir / var/lib/mongo2 [root@test3] # mongod-- shardsvr-- replSet shard-b-- dbpath / var/lib/mongo2/-- port 37017-- logpath / var/log/mongodb/mongod2.log-- fork-- journalabout to fork child process, waiting until server is ready for connections.forked process: 4303child process started successfully, parent exiting

Configure shard-b replica set

[root@test1] # mongo test1.lan:37017MongoDB shell version v3.4.3connecting to: test1.lan:37017MongoDB server version: 3.4.3Server has startup warnings: 2017-04-24T22:59:43.476+0800 I STORAGE [initandlisten] 2017-04-24T22:59:43.476+0800 I STORAGE [initandlisten] * * WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine2017-04-24T22:59:43.476+0800 I STORAGE [initandlisten] * * See http://dochub .mongodb.org/core/prodnotes-filesystem2017-04-24T22:59:44.019+0800 I CONTROL [initandlisten] > rs.initiate () {"info2": "no configuration specified. Using a default configuration for the set "," me ":" test1.lan:37017 "," ok ": 1} shard-b:SECONDARY > shard-b:PRIMARY > config = rs.config () {" _ id ":" shard-b "," version ": 1," protocolVersion ": NumberLong (1) "members": [{"_ id": 0, "host": "test1.lan:37017", "arbiterOnly": false, "buildIndexes": true, "hidden": false "priority": 1, "tags": {}, "slaveDelay": NumberLong (0), "votes": 1}] "settings": {"chainingAllowed": true, "heartbeatIntervalMillis": 2000, "heartbeatTimeoutSecs": 10, "electionTimeoutMillis": 10000, "catchUpTimeoutMillis": 2000, "getLastErrorModes": {} "getLastErrorDefaults": {"w": 1, "wtimeout": 0} "replicaSetId": ObjectId ("58fe1465f7a2e985d87b8bf8")} shard-b:PRIMARY > config.members [0] .priority = 22shard-b:PRIMARY > rs.reconfig (config) {"ok": 1} shard-b:PRIMARY > rs.add ("test2.lan:37017") {"ok": 1} shard-b:PRIMARY > rs.add ("test3.lan:37017") {"ok": 1} shard-b:PRIMARY > rs.isMaster ( ) {"hosts": ["test1.lan:37017" "test2.lan:37017", "test3.lan:37017", "setName": "shard-b", "setVersion": 4, "ismaster": true, "secondary": false, "primary": "test1.lan:37017", "me": "test1.lan:37017" "electionId": ObjectId ("7fffffff0000000000000001"), "lastWrite": {"opTime": {"ts": Timestamp (1493046429, 1), "t": NumberLong (1)}, "lastWriteDate": ISODate ("2017-04-24T15:07:09Z")} "maxBsonObjectSize": 16777216, "maxMessageSizeBytes": 48000000, "maxWriteBatchSize": 1000, "localTime": ISODate ("2017-04-24T15:07:24.475Z"), "maxWireVersion": 5, "minWireVersion": 0, "readOnly": false, "ok": 1}

So that the two replica sets of shard-a shard-b have been configured

Starting to configure config server,MongoDB from version 3.2, it is stipulated that config server must also enable the replica set feature.

The configuration file of config server is as follows: config server generally listens on port 27019

# mongod.conf# for documentation of all options See:# http://docs.mongodb.org/manual/reference/configuration-options/# where to write logging data.systemLog: destination: file logAppend: true path: / var/log/mongodb/mongod.log# Where and how to store data.storage: dbPath: / var/lib/mongo journal: enabled: true# engine:# mmapv1:# wiredTiger:# how the process runsprocessManagement: fork: true# fork and run in background pidFilePath: / var/run/mongodb/mongod.pid # location of pidfile# network interfacesnet: port: 27019 bindIp: 0.0.0.0 # Listen to local interface only Comment to listen on all interfaces.#security:#operationProfiling:replication: replSetName: cfgReplSetsharding: clusterRole: configsvr## Enterprise-Only Options#auditLog:#snmp:

Start the mongod service of three config server

[root@test4 ~] # service mongod startStarting mongod: [OK] [root@test5 ~] # service mongod startStarting mongod: [OK] [root@test6 ~] # service mongod startStarting mongod: [OK]

Similarly, the copy set configuration for config server is as shown above, and the code here is omitted.

Configure startup mongos routing host

[root@test7] # mongos-- configdb cfgReplSet/test4.lan,test5.lan,test6.lan:27019-- logpath / var/log/mongodb/mongos.log-- fork-- port 30000about to fork child process, waiting until server is ready for connections.forked process: 3338child process started successfully, parent exiting

When starting mongos with MongoDB version > 3.2, you need to follow the replica set name of config server (in this case, cfgReplSet)

Connection mongos test

[root@test7] # mongo test7.lan:30000MongoDB shell version v3.4.4connecting to: test7.lan:30000MongoDB server version: 3.4.4Server has startup warnings: 2017-04-24T23:30:47.285+0800 I CONTROL [main] 2017-04-24T23:30:47.285+0800 I CONTROL [main] * * WARNING: Access control is not enabled for the database.2017-04-24T23:30:47.285+0800 I CONTROL [main] * * Read and write access to data and configuration Is unrestricted.2017-04-24T23:30:47.285+0800 I CONTROL [main] * * WARNING: You are running this process as the root user Which is not recommended.2017-04-24T23:30:47.285+0800 I CONTROL [main] mongos > show dbsadmin 0.000GBconfig 0.000GBmongos > use configswitched to db configmongos > show collectionschunkslockpingslocksmigrationsmongosshardstagsversionmongos > db.shards.find () # No document is returned here It also indicates that no available sharding cluster has been added to the sharding cluster.

Configure sharding cluster: shard

Mongos > sh.addShard ("shard-a/test1.lan,test2.lan,test3.lan") {"shardAdded": "shard-a", "ok": 1} mongos > db.shards.find () {"_ id": "shard-a", "host": "shard-a/test1.lan:27017,test2.lan:27017,test3.lan:27017", "state": 1} mongos > sh.addShard ("shard-b/test1.lan:37017,test2.lan:37017" Test3.lan:37017 ") {" shardAdded ":" shard-b "," ok ": 1} mongos > db.shards.find () {" _ id ":" shard-a "," host ":" shard-a/test1.lan:27017,test2.lan:27017,test3.lan:27017 "," state ": 1} {" _ id ":" shard-b "," host ":" shard-b/test1.lan:37017,test2.lan:37017 " Test3.lan:37017 "," state ": 1} # check the number of sharded replica sets in the sharding cluster Method one: Mongos > db.getSiblingDB ('config'). Shards.find () {"_ id": "shard-a", "host": "shard-a/test1.lan:27017,test2.lan:27017,test3.lan:27017", "state": 1} {"_ id": "shard-b", "host": "shard-b/test1.lan:37017,test2.lan:37017,test3.lan:37017" "state": 1} # check the number of sharded replica sets in the sharding cluster Method two Mongos > use adminswitched to db adminmongos > db.runCommand ({listshards: 1}) {"shards": [{"_ id": "shard-a", "host": "shard-a/test1.lan:27017,test2.lan:27017,test3.lan:27017" "state": 1}, {"_ id": "shard-b", "host": "shard-b/test1.lan:37017,test2.lan:37017,test3.lan:37017" "state": 1}], "ok": 1} # check the number of shard replica sets in the sharding cluster Method three

Configure the shard collection: the next step is to start sharding on the database. Fragmentation is not done automatically, but needs to be set up for the collection in advance in the database.

Mongos > sh.enableSharding ("test2_db") # the library can be existing or non-existent {"ok": 1} mongos > db.getSiblingDB ("config"). Databases.find () {"_ id": "test2_db", "primary": "shard-a", "partitioned": true} # sharding sharding library databases collection already has the corresponding configuration record. Mongos > sh.status ()-Sharding Status-sharding version: {"_ id": 1, "minCompatibleVersion": 5, "currentVersion": 6, "clusterId": ObjectId ("58fe17e90b3df66581ff6b09")} shards: {"_ id": "shard-a", "host": "shard-a/test1.lan:27017,test2.lan:27017,test3.lan:27017" "state": 1} {"_ id": "shard-b", "host": "shard-b/test1.lan:37017,test2.lan:37017,test3.lan:37017" "state": 1} active mongoses: "3.4.4": 1 autosplit: Currently enabled: yes balancer: Currently enabled: yes Currently running: no Balancer lock taken at Mon Apr 24 2017 23:21:13 GMT+0800 (CST) by ConfigServer:Balancer Failed balancer rounds in last 5 attempts: 0 Migration Results for the last 24 hours: No recent migrations databases: {"_ id": "test2_db" "primary": "shard-a", "partitioned": true} # it is more convenient to view the status information of the current part in the shard status It includes sharding cluster members, sharding database, slicing mechanism and so on. Mongos > sh.shardCollection ("test2_db.users", {username: 1, _ id: 1}) {"collectionsharded": "test2_db.users", "ok": 1} # here, we choose username _ id as the combined sharding key, which must be an index # if the collection is empty, the command automatically creates the index in the collection, if the corresponding data already exists in the collection And the index of the key combination is not created in advance, then this statement will throw an error # you need to manually go to the collection to create the index of the combination After that, it can be used as the sharding key mongos > db.getSiblingDB ("config"). Collections.find (). Pretty () {"_ id": "test2_db.users", "lastmodEpoch": ObjectId ("58fe21de224dc86230e9a8f7"), "lastmod": ISODate ("1970-02-19T17:02:47.296Z"), "dropped": false, "key": {"username": 1 "_ id": 1}, "unique": false} # after the configuration is completed Config.collections has the sharding key information of the corresponding set.

Let's take a look at the existence of a fragment set in a separate fragment copy set.

First of all, you need to find out which shard the library has been assigned to (since there is no data before, when the sharding key is created, the index data is automatically inserted and automatically routed to one of the sharding key clusters according to the default configuration)

Mongos > sh.status ()-Sharding Status-sharding version: {"_ id": 1, "minCompatibleVersion": 5, "currentVersion": 6, "clusterId": ObjectId ("58fe17e90b3df66581ff6b09")} shards: {"_ id": "shard-a", "host": "shard-a/test1.lan:27017,test2.lan:27017,test3.lan:27017" "state": 1} {"_ id": "shard-b", "host": "shard-b/test1.lan:37017,test2.lan:37017,test3.lan:37017" "state": 1} active mongoses: "3.4.4": 1 autosplit: Currently enabled: yes balancer: Currently enabled: yes Currently running: no Balancer lock taken at Mon Apr 24 2017 23:21:13 GMT+0800 (CST) by ConfigServer:Balancer Failed balancer rounds in last 5 attempts: 0 Migration Results for the last 24 hours: No recent migrations databases: {"_ id": "test2_db" "primary": "shard-a", "partitioned": true} test2_db.users shard key: {"username": 1 "_ id": 1} unique: false balancing: true chunks: shard-a 1 {"username": {"$minKey": 1} "_ id": {"$minKey": 1}}-- > > {"username": {"$maxKey": 1}, "_ id": {"$maxKey": 1}} on: shard-a Timestamp (1,0) # the last line of databases sees The chunks of the library is assigned to the shard-a replica set, so we can then go directly to shard-a to view the document information of the users collection in the library. # Log in to the shard-a replica set to view shard-a:PRIMARY > show dbsadmin 0.000GBlocal 0.000GBtest2_db 0.000GBshard-a:PRIMARY > use test2_dbswitched to db test2_dbshard-a:PRIMARY > db.users.find () # the collection has no documentation for the time being shard-a:PRIMARY > db.users.getIndexes () # View the index configuration information of the collection [{"v": 2 "key": {"_ id": 1}, "name": "_ id_", "ns": "test2_db.users"}, {"v": 2 "key": {"username": 1, "_ id": 1}, "name": "username_1__id_1", "ns": "test2_db.users"} # see two indexes The first index _ id is the index added by default by the system, and the second index is the key combination index that is automatically created when the sharding key is created.]

Write data to the sharding cluster

# first create a data object to fill the document size mongos > data = new Array (2049). Join ("abcd") mongos > data.length10240# data size is 1MBmongos > for (var item0; I)

< 100; i++){... db.getSiblingDB("test2_db").users.insert({... username: "Join" + i,... age: i % 13 + 20,... data: data }... )... }WriteResult({ "nInserted" : 1 })# 批量插入 100 条文档，每个文档约为 1MB 大小。# 接下来看看有了这么多文档过后，会怎么分片。mongos>

After db.getSiblingDB ("config"). Chunks.count () inserts so much data, you will find several more blocks. We can verify this conjecture mongos > db.getSiblingDB ("config") .chunks.find () .pretty () {"_ id": "test2_db.users-username_MinKey_id_MinKey", "lastmod": Timestamp (2,1), "lastmodEpoch": ObjectId ("58fe21de224dc86230e9a8f7"), "ns": "test2_db.users" by checking the number of databases in the collection. "min": {"username": {"$minKey": 1}, "_ id": {"$minKey": 1}}, "max": {"username": "Join1", "_ id": ObjectId ("58fe293756525c8a54e2a5af")} "shard": "shard-a"} {"_ id": "test2_db.users-username_\" Join1\ "_ id_ObjectId ('58fe293756525c8a54e2a5af')", "lastmod": Timestamp (1,2), "lastmodEpoch": ObjectId ("58fe21de224dc86230e9a8f7"), "ns": "test2_db.users", "min": {"username": "Join1" "_ id": ObjectId ("58fe293756525c8a54e2a5af")}, "max": {"username": "Join2", "_ id": ObjectId ("58fe293756525c8a54e2a5b0")} "shard": "shard-a"} {"_ id": "test2_db.users-username_\" Join2\ "_ id_ObjectId ('58fe293756525c8a54e2a5b0')", "lastmod": Timestamp (2,0), "lastmodEpoch": ObjectId ("58fe21de224dc86230e9a8f7"), "ns": "test2_db.users", "min": {"username": "Join2" "_ id": ObjectId ("58fe293756525c8a54e2a5b0")}, "max": {"username": {"$maxKey": 1}, "_ id": {"$maxKey": 1}}, "shard": "shard-b"} # View the detailed sharding information of each data block It is found that two blocks are stored in the shard-a replica set and one data block is stored in the shard-b replica set. We can also see the relevant information more intuitively through sh.status (). Mongos > sh.status ()-Sharding Status-sharding version: {"_ id": 1, "minCompatibleVersion": 5, "currentVersion": 6, "clusterId": ObjectId ("58fe17e90b3df66581ff6b09")} shards: {"_ id": "shard-a", "host": "shard-a/test1.lan:27017,test2.lan:27017,test3.lan:27017" "state": 1} {"_ id": "shard-b", "host": "shard-b/test1.lan:37017,test2.lan:37017,test3.lan:37017" "state": 1} active mongoses: "3.4.4": 1 autosplit: Currently enabled: yes balancer: Currently enabled: yes Currently running: no Balancer lock taken at Mon Apr 24 2017 23:21:13 GMT+0800 (CST) by ConfigServer:Balancer Failed balancer rounds in last 5 attempts: 0 Migration Results for the last 24 hours: 1: Success databases: {"_ id": "test2_db" "primary": "shard-a", "partitioned": true} test2_db.users shard key: {"username": 1 "_ id": 1} unique: false balancing: true chunks: shard-a 2 shard-b 1 {"username": {"$minKey": 1} "_ id": {"$minKey": 1}}-- > {"username": "Join1", "_ id": ObjectId ("58fe293756525c8a54e2a5af")} on: shard-a Timestamp (2,1) {"username": "Join1", "_ id": ObjectId ("58fe293756525c8a54e2a5af")}-- > {"username": "Join2" "_ id": ObjectId ("58fe293756525c8a54e2a5b0")} on: shard-a Timestamp (1,2) {"username": "Join2", "_ id": ObjectId ("58fe293756525c8a54e2a5b0")}-- > {"username": {"$maxKey": 1}, "_ id": {"$maxKey": 1}} on: shard-b Timestamp (2) 0) # this method prints all database information And contains scope information.

Behind the surface, the underlying MongoDB relies on two mechanisms to maintain the balance of the cluster: segmentation and migration.

Segmentation is the process of dividing a large database into two smaller blocks. It occurs only when the block size exceeds the maximum limit, and the current default setting is 64MB. Segmentation is necessary because data blocks are too large to be distributed across the collection.

Migration is the process of moving data blocks between shards. The migration process is triggered when some sharding servers contain much more data blocks than other sharding servers. This trigger is called migration round. In a migration round, data blocks are migrated from some sharding servers to other sharding servers until the cluster appears to be relatively balanced. We can imagine that these two operations are much more expensive to migrate than to split.

In fact, these operations should not affect us, but it is useful to understand that they may be migrating data when you encounter performance problems. If the inserted data is evenly distributed and the datasets on each shard should grow at about the same rate, migration should not occur frequently.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.