Three-part Mongo server cluster configuration Learning

Mongo server cluster configuration learning the three-part MongoDB sharding mainly refers to the process of splitting the set into small blocks and separate them on different servers. Apsaradb for MongoDB supports automatic sharding to free you from manual sharding management. Use shards in the following situations: 1. The server disk is not enough. 2. A single Mongod cannot meet the performance requirements of Data Writing. 3.

Mongo server cluster configuration learning the three-part MongoDB sharding mainly refers to the process of splitting the set into small blocks and separate them on different servers. Apsaradb for MongoDB supports automatic sharding to free you from manual sharding management. Use shards in the following situations: 1. The server disk is not enough. 2. A single Mongod cannot meet the performance requirements of Data Writing. 3.

Mongo server cluster configuration learning 3-sharding

MongoDB sharding mainly refers to the process of splitting a set into small blocks and having them on different servers. Apsaradb for MongoDB supports automatic sharding to free you from manual sharding management.
You need to use parts in the following situations:
1. The server disk is not enough.
2. A single Mongod cannot meet the performance requirements of Data Writing.
3. Put big data into the memory to improve performance.
For the partition structure we want to implement:

We can see that the original Mongod node is divided into two parts: A and B. Route D reads and configures the sharding policy of server C, and then decides the shard where the data is stored, while routing hides the details of decision-making, users can directly access the route to enjoy the advantages of the shard, without having to care about the details of the shard read by the route.
Configuration steps:
1. Create a configuration server C
Create the following configuration file, port 10000, and start mongod-f config. cnf

Dbpath = D: \ mongodb \ test \ sharded \ C \ Data
Bind_ip = 127.0.0.1
Port = 10000

2. Create a route server D
The vro configuration file is as follows:

Bind_ip = 127.0.0.1
Port = 20000
Configdb = 127.0.0.1: 10000

Configdb = 127.0.0.1: 10000 is the address of the server configured for the route listener.
Vro started with mongos

Mongos-f config. cnf

Note: The configuration server must be started first because the Routing Server needs to listen to the configuration server.
3. Create A partition server A and B
Configure A, and then start

Dbpath = D: \ mongodb \ test \ sharded \ A \ Data
Bind_ip = 127.0.0.1
Port = 8001

B configuration, and then start B

Dbpath = D: \ mongodb \ test \ sharded \ B \ Data
Bind_ip = 127.0.0.1
Port = 8002

4. establish a connection between the slice server and the router in the Cluster
This operation needs to be configured in the vro, open the vroshell shell, and execute database commands
Db. runCommand ({addshard: "127.0.0.1: 8001", allowLocal: true })
Db. runCommand ({addshard: "127.0.0.1: 8002", allowLocal: true })


You can see that the operations for adding shards are performed in the admin database.
5. Add the sharding function for the Business Database
Add the sharding function for person and execute db. runCommand ({"enablesharding": "person"}) in the route "})
6. sharding for the set
Partition key: a key in the set as the basis for splitting.
Sharding is performed for the info set of the person library. The key field sets the partition key.
Run the following command db. runCommand ({"shardcollection": "person.info", "key": {"_ id": 1 }})
7. Add a certain amount of data to test the sharding function.
Insert 0.8 million data records using scripts
For (I = 1; I <= 800001; I ++ ){
Db.info. insert ({name: I })
}
Query the data volume on the partition server A and server B respectively. We can see that the 800001 data records have been stored in two shards respectively.


Formal environment Configuration
Successful sharding requires the following conditions:
1. Multiple configuration servers
2. Multiple mongos servers
3. Each slice is a replica set
1. Multiple configuration servers
Create a configuration server as shown above. Now, when starting mongos, connect it to these three configuration servers. Assume that the port number of the three configuration files is 20001 ~ 20003
Mongos -- configdb localhost: 20001, localhost: 20002, localhost: 20003
The configuration server uses the two-step commit mechanism instead of the normal asynchronous replication of MongoDB to maintain different copies of cluster configurations. This ensures the consistency of the cluster status. This means that after a configuration server is down, the cluster configuration information will be read-only. However, the client can still read and write data. Data can be rebalanced only after all configuration servers are backed up.
2. Multiple mongos
The number of Mongos is unlimited. We recommend that you run only one mongos process on an application server. In this way, each application server can have a local session with mongos.
3. Each slice is a replica set
In the production environment, each slice should be a replica set. In this way, the failure of a single server will not cause the failure of the entire slice. You can use the addshard command to add a replica set as a part. When adding a replica set, you only need to specify the name and seed of the replica set.
The multipart storage that achieves data is also capable of automatic backup and fault repair. It can be used in combination with replica sets and shards to build an architecture such, (For example, only replica set configuration is performed for shardA)

1. modify the configuration of A as follows:

Dbpath = D: \ mongodb \ test \ sharded \ A \ Data
Bind_ip = 127.0.0.1
Port = 8001
ReplSet = replicademo/127.0.0.1: 8003

The new A1 and A2 nodes and A constitute A replica set.
A1 Configuration:

Dbpath = D: \ mongodb \ test \ sharded \ A1 \ Data
Bind_ip = 127.0.0.1
Port = 8004
ReplSet = replicademo/127.0.0.1: 8003

A2 Configuration:

Dbpath = D: \ mongodb \ test \ sharded \ A2 \ Data
Bind_ip = 127.0.0.1
Port = 8003
ReplSet = replicademo/127.0.0.1: 8001

Execute replica set comfort in shell

Db. runCommand ({"replSetInitiate ":
{
"_ Id": 'replicademo ',
"Members ":[
{
"_ Id": 1,
"Host": "127.0.0.1: 8001"
},
{
"_ Id": 2,
"Host": "127.0.0.1: 8003"
},
{
"_ Id": 3,
"Host": "127.0.0.1: 8004"
}
]
}
})

In this way, the replica set of A, A1, and A2 is created. The query configuration shows that A is an active node, for example:

Go back to the vro and set the shard configuration.
Mongos> db. runCommand ({addshard: "replicademo/127.0.0.1: 8001 "})
In this way, mongos will know that it is connected to the replicademo replica set. After the active nodes are down, they will find new active nodes.
Run db. printShardingStatus () and you will see that all nodes in the replica set have been automatically configured, for example:


Manage parts
The shard information is mainly stored in the config database, so that it can be accessed by any process connected to mongos.
Configuration set
The following code assumes that mongos has been connected to the shell and you have run use config.
1. slices
You can find all the shards in the shards set> db. shards. find ();
2. Database
The databases set contains the list of databases on the disk and related information.
> The db. databases. find () Key is explained as follows:
"_ Id": indicates the data name.
"Partitioned": whether to enable the sharding Function
"Primary": This value corresponds to "_ id", indicating where the data base camp is. That is, the location where the database file is created.
3. Block
The block information is saved in the chunks set. You can see how the data is split into clusters.
> Db. chunks. find ()
Partition command
1. Obtain the summary
> Db. printShardingStatus () provides an overview of the Set mentioned above
2. delete a part
With removeshard, you can delete a part from the cluster. removeshard moves all the parts on the given part to other parts.
> Db. runCommand ({"removeshard": "localhost: 10000 "})