Configure MongoDB sharding cluster-Taobao DBA

Document directory

• Sharding cluster Introduction
• In this example, the actual environment architecture
• Software preparation
• Configure relica Sets
• Configure three config servers
• Configure mongs
• Refreshing the shard Cluster
• Collecton sharding
• Multipart collection example

Sharding cluster Introduction

This is a horizontally scalable mode, which is especially powerful when the data volume is large. In practice, large-scale applications generally use this architecture to build a monodb system.

To build a MongoDB sharding cluster, three roles are required:

Shard server: mongod instance, used to store actual data blocks. In the actual production environment, a role of shard server can be assumed by one relica set of several machines to prevent single point of failure (spof) on the host.

Config server: mongod instance, which stores the entire cluster metadata, including chunk information.

Route server: A mongos instance, with frontend routing and access from the client. It makes the entire cluster look like a single database, and front-end applications can be used transparently.

Sharding architecture diagram:

In this example, the actual environment architecture

Architecture example:

1. Run a mongod instance (called mongod shard11, mongod shard12, and mongod shard13) on three machines respectively to organize replica set1 as shard1 of the cluster.
2. Run a mongod instance (called mongod shard21, mongod shard22, mongod shard23) on three machines respectively to organize replica set2 as shard2 of the cluster.
3. Each machine runs a mongod instance as three config servers.
4. Each machine runs a mongs process for client connection.

Host	IP	Port Information
Server1	10.1.1.1	Mongod shard11: 27017 Mongod shard12: 27018 Mongod config1: 20000 Mongs1: 30000
Server2	10.1.1.2	Mongod shard12: 27017 Mongod shard22: 27018 Mongod config2: 20000 Mongs2: 30000
Server3	10.1.1.3	Mongod shard13: 27017 Mongod shard23: 27018 Mongod config3: 20000 Mongs3: 30000

Software preparation

Software preparation
1. Create a user
Groupadd-G 20001 MongoDB
Useradd-u 20001-G MongoDB
Passwd MongoDB

2. Install monodb Software
Su-MongoDB
Tar zxvf mongodb-linux-x86_64-1.6.2.tar
After installation, the directory structure is as follows:
$ Tree mongodb-linux-x86_64-1.6.2
Mongodb-linux-x86_64-1.6.2
|-GNU-AGPL-3.0
|-Readme
|-Third-Party-notices
'-Bin
|-Bsondump
|-Mongo
|-Mongod
|-Mongodump
|-Export Export
|-Program Files
|-Export Import
|-Mongorestore
|-Mongos
|-Sniff
'-Unzip stat
1 directory, 14 files

3. Create a data directory
Create a shard data file directory on each server according to the sharding architecture diagram in this example.
Server1:
Su-monodb
CD/home/monodb
Mkdir-p Data/shard11
Mkdir-p Data/shard21
Server2:
Su-monodb
CD/home/monodb
Mkdir-p Data/shard11
Mkdir-p Data/shard22
Server3:
Su-monodb
CD/home/monodb
Mkdir-p Data/shard13
Mkdir-p Data/shard23

Configure relica Sets

1. Configure the replica sets used by shard1:
Server1:
CD/home/MongoDB/mongodb-linux-x86_64-1.6.2/bin
./Mongod-shardsvr-replset shard1-port 27017-dbpath/home/MongoDB/data/shard11-oplogsize 100-logpath/home/MongoDB/data/shard11.log-logappend-Fork

Server2:
CD/home/MongoDB/mongodb-linux-x86_64-1.6.2/bin
./Mongod-shardsvr-replset shard1-port 27017-dbpath/home/MongoDB/data/shard12-oplogsize 100-logpath/home/MongoDB/data/shard12.log-logappend-Fork

Server3:
CD/home/MongoDB/mongodb-linux-x86_64-1.6.2/bin
./Mongod-shardsvr-replset shard1-port 27017-dbpath/home/MongoDB/data/shard13-oplogsize 100-logpath/home/MongoDB/data/shard13.log-logappend-Fork

Initialize replica set
Connect one mongod with Mongo and run the following command:
> Config = {_ ID: 'shard1 ', members :[
{_ ID: 0, host: '10. 1.1.1: 27017 '},
{_ ID: 1, host: '10. 1.1.2: 27017 '},
{_ ID: 2, host: '10. 1.1.3: 27017 '}]
}

> Rs. Initiate (config );

In the same way, configure the replica sets used by shard2:
Server1:
CD/home/MongoDB/mongodb-linux-x86_64-1.6.2/bin
./Mongod-shardsvr-replset shard2-port 27018-dbpath/home/MongoDB/data/shard21-oplogsize 100-logpath/home/MongoDB/data/shard21.log-logappend-Fork

Server2:
CD/home/MongoDB/mongodb-linux-x86_64-1.6.2/bin
./Mongod-shardsvr-replset shard2-port 27018-dbpath/home/MongoDB/data/shard22-oplogsize 100-logpath/home/MongoDB/data/shard22.log-logappend-Fork

Server3:
CD/home/MongoDB/mongodb-linux-x86_64-1.6.2/bin
./Mongod-shardsvr-replset shard2-port 27018-dbpath/home/MongoDB/data/shard23-oplogsize 100-logpath/home/MongoDB/data/shard23.log-logappend-Fork

Initialize replica set
Connect one mongod with Mongo and run the following command:
> Config = {_ ID: 'shard2 ', members :[
{_ ID: 0, host: '10. 1.1.1: 27018 '},
{_ ID: 1, host: '10. 1.1.2: 27018 '},
{_ ID: 2, host: '10. 1.1.3: 27018 '}]
}

> Rs. Initiate (config );

Now we have configured two replica sets, that is, we have prepared two shards.

Configure three config servers

Server1:
Mkdir-P/home/MongoDB/data/config
./Mongod-configsvr-dbpath/home/MongoDB/data/config-port 20000-logpath/home/MongoDB/data/config. Log-logappend-fork # dbpath is also required for config Server
 
Server2:
Mkdir-P/home/MongoDB/data/config
../Mongod-configsvr-dbpath/home/MongoDB/data/config-port 20000-logpath/home/MongoDB/data/config. Log-logappend-Fork

Server3:
Mkdir-P/home/MongoDB/data/config
../Mongod-configsvr-dbpath/home/MongoDB/data/config-port 20000-logpath/home/MongoDB/data/config. Log-logappend-Fork

Configure mongs

Run the following commands on Server 1, Server 2, and Server 3:
./Mongos-configdb 10.1.1.1: 20000, 10.1.1.2: 20000, 10.1.1.3: 20000-port 30000-chunksize 5-logpath/home/MongoDB/data/mongos. Log-logappend-Fork
# Dbpath is not required for mongs

Refreshing the shard Cluster

Connect to one of the mongos processes and switch to the admin database for the following configuration
1. Connect to mongs and switch to Admin
./Mongo 10.1.1.1: 30000/admin
> DB
Admin
2. Join shards
For example, if Shard is a single server, use> dB. runcommand ({addshard: "<serverhostname> [: <port>]"}) is added. If Shard is a replica set, replicasetname/<serverhostname> [: port] [, serverhostname2 [: Port],…] The format is as follows:
> DB. runcommand ({addshard: "shard1/10.1.1.1: 27017, 10.1.1.2: 27017, 10.1.1.3: 27017", name: "S1", maxsize: 20480 });
> DB. runcommand ({addshard: "shard2/10.1.1.1: 27018, 10.1.1.2: 27018, 10.1.1.3: 27018", name: "S2", maxsize: 20480 });
Note: When the second Shard is added, an error occurs: Test Database. Here, the Mongo command is used to connect to the second replica set and DB. the dropdatabase () command deletes the test database and then adds it

3. Optional parameters
Name: used to specify the name of each shard. If this parameter is not specified, the system will automatically allocate
Maxsize: specifies the maximum disk space available for each shard. The unit is megabytes.

4. Listing shards
> DB. runcommand ({listshards: 1 })
If the two shards you added are listed, the shards has been configured successfully.

5. Activate database shards
Command:
> DB. runcommand ({enablesharding: "<dbname> "});
By executing the above commands, you can make the database span shard. If you do not execute this step, the database will only store it in one shard. Once the database Shard is activated, different collections in the database will be stored on different Shard, but a collection is still stored on the same shard. to split a collection, you must perform some operations on the collection separately.

Collecton sharding

To enable multipart storage for a single collection, you must specify a shard key for the collection and run the following command:
> DB. runcommand ({shardcollection: "<namespace>", key: <shardkeypatternobject> });
Note:
A. The multipart collection system automatically creates an index (you can also create an index in advance)
B. The collection of shards can only have one unique index on the shard key. Other unique indexes are not allowed.
One note: A sharded collection can have only one unique index, which must exist on the shard key. No other unique indexes can exist on the collection.

Multipart collection example

> DB. runcommand ({shardcollection: "test. C1", key: {ID: 1 }})
> For (VAR I = 1; I <= 200003; I ++) dB. c1.save ({ID: I, value1: "1234567890", value2: "1234567890", value3: "1234567890", value4: "1234567890 ″});
> DB. c1.stats ()
{
"Sharded": True,
"Ns": "test. C1 ″,
"Count": 200003,
"Size": 25600384,
"Avgobjsize": 128,
"Storagesize": 44509696,
"Nindexes": 2,
"Nchunks": 15,
"Shards ":{
"S1 ″:{
"Ns": "test. C1 ″,
"Count": 141941,
"Size": 18168448,
"Avgobjsize": 128,
"Storagesize": 33327616,
"Numextents": 8,
"Nindexes": 2,
"Lastextentsize": 12079360,
"Paddingfactor": 1,
"Flags": 1,
"Totalindexsize": 11157504,
"Indexsizes ":{
"_ Id _": 5898240,
"Id_1": 5259264
},
"OK": 1
},
"S2 ″:{
"Ns": "test. C1 ″,
"Count": 58062,
"Size": 7431936,
"Avgobjsize": 128,
"Storagesize": 11182080,
"Numextents": 6,
"Nindexes": 2,
"Lastextentsize": 8388608,
"Paddingfactor": 1,
"Flags": 1,
"Totalindexsize": 4579328,
"Indexsizes ":{
"_ Id _": 2416640,
"Id_1": 2162688
},
"OK": 1
}
},
"OK": 1
}