MongoDB: a simple example of configuring two shared instances

In the following example, two shared services, one Configuration Service and one mongos service are enabled. All these services are tested on the same server. Of course, they can also be deployed on different servers.

1. Create a Shards instance

Start a pair of shared services on the local machine

1. $ Mkdir/data/db/a/data/db/B
2. $./Mongod -- shardsvr -- dbpath/data/db/a -- port 10000>/tmp/sharda. log &
3. $ Cat/tmp/sharda. log
4. $./Mongod -- shardsvr -- dbpath/data/db/B -- port 10001>/tmp/shardb. log &
5. $ Cat/tmp/shardb. log

2. Start configuration and mongos Service

Start the Configuration Service and the mongos service,

1. $ Mkdir/data/db/config
2. $./Mongod -- configsvr -- dbpath/data/db/config -- port 20000>/tmp/configdb. log &
3. $ Cat/tmp/configdb. log
4. $./Mongos -- configdb localhost: 20000>/tmp/mongos. log &
5. $ Cat/tmp/mongos. log

Here, mongos does not need to specify a data directory. All the data required by mongos is obtained from the configuration server. Of course, the configuration server here can also be a cluster, which can improve availability.

Of course, the two shard and Configuration Services can be distributed on different machines, as long as the corresponding IP address is specified here. All services are deployed on the same server for testing.

NOTE: The default chunk size of mongos is 200 MB. You can set the chunk size when starting the mongos service, in MB, when two shard servers balance data, data is migrated in chunk units.

1. $./Mongos -- configdb localhost: 20000 -- chunkSize 1>/tmp/mongos. log &

Set chunkSize to 1 MB.

3. Connect to the mongos Service

If you connect to the service on the local machine, you only need to run the./mongo command. The default connection port number is 27017. Of course, you can also connect to a remote server. here you need to specify the IP address of the machine.

Next we will configure the shard after connecting to mongos.

1. $./Mongo
2. MongoDB shell version: 1.6.0
3. Connecting to: test
4. > Use admin// The administrator must be used for configuration.
5. Switched to db admin
6. > Db. runCommand ({addshard:"Localhost: 10000"})// Add the shard Node
7. {"Shardadded":"Shard0000","OK": 1}
8. > Db. runCommand ({addshard:"Localhost: 10001"})
9. {"Shardadded":"Shard0001","OK": 1}

Next, you need to specify the database to be segmented, and the table in the database must specify a corresponding key or multiple keys. This is used to split the data.

1. > Db. runCommand ({enablesharding:"Test"})
2. {"OK": 1}
3. > Db. runCommand ({shardcollection:"Test. people", Key: {name: 1 }})
4. {"OK": 1} 

4. Check the database status.

1. > Use config
2. Switched to db config
3. > Show collections
4. Chunks
5. Databases
6. Lockpings
7. Locks
8. Mongos
9. Settings
10. Shards
11. System. indexes
12. Version 

These tables contain all the information about the block configuration.

5. Relationship between chunks and replication.

Data Partitioning is equivalent to scaling out the database. the centrally managed data is managed on different spof to improve the scalability of the database. The replication mentioned above is prepared to improve data availability. It will not affect data availability because of a node failure.

The figure below shows that horizontal scaling (shared) and vertical replication form a data array.