Mongodb sharding (6): configservers and shards

1. When a shard is unavailable, the entire sharding cluster is unavailable. Only the config database can read and write data, and data migration and chunks are stopped.

For example, there are three shard in the cluster. Now I have stopped the shard shard0001 before performing the query operation and found that the operation failed.

It can be seen from this that if a shard only has one mongod process instead of the replSet mode, the entire cluster will be unavailable when the process goes down. Therefore, each shard must be in the replSet mode.

2. Add the down configServer again.

(1) restore its data. Copy one of the running configsServers data directory files.

(2) Start. View mongos logs.

3. Add a new configServer

(1) copy data. Stop a running instance. Copy its data directory file to the data directory of the new configServer. (The selected configServer must be stopped first. The config data is read-only and cannot be changed at this time. In this case, copying is the safest .) Note that the number of configservers is only 1 and 3. Otherwise, an error is reported during startup.

(2) Stop mongs and mongds in sequence.

(3) Start configServers. Check whether logs are started properly. (Including existing and newly added .)

(4) Start mongs and modify the original configdb parameter value.

(5) Start ipvds.