In this blog, we mainly discuss blog management. Since we have already written detailed examples in the previous five articles, we will not illustrate them here. 1. Monitoring of sharded clusters is a complex component of the entire system. Therefore, monitoring is more necessary. Main commands: serverstatus and currentOp () 2. Manual partitioning manual partitioning means manual cabling
In this blog, we mainly discuss blog management. Since we have already written detailed examples in the previous five articles, we will not illustrate them here. 1. Monitoring of sharded clusters is a complex component of the entire system. Therefore, monitoring is more necessary. Main commands: serverstatus and currentOp () 2. Manual partitioning manual partitioning means manual cabling
In this blog, we mainly discuss blog management. Since we have already written detailed examples in the previous five articles, we will not illustrate them here.
I. Monitoring
Sharding cluster is a complex part of the system. Therefore, monitoring is needed.
Main commands: serverstatus and currentOp ()
Ii. Manual partitioning
Manual partitioning means to manually split and migrate the blocks of the online sharding cluster. Generally, the larger the number of write shards, the larger the number of shards. The movechunk command is also helpful in this case.
3. Add a shard
Sh. addShard ("computername: port ")
To increase the capacity in this way, pay attention to the time it takes to migrate data to the new shard. The estimated migration speed is 100 to per minute ~ 200 M. It is best to add new shards when the index and working set reach the existing plan.
4. delete parts
In some rare cases, you may want to delete a part by running the removeshard command. Once the shards are cleared, make sure that the shards to be deleted are not the primary shards of the database. Run the config. databases set command to query the shards;
Db. databases. find ()
5. Split a set
Although you can delete a part, the part of the set is not removed from the formal path. The practice is to use the mongodump command to export data and then use mongorestore to restore data.
Vi. Backup part set
To back up a sharded cluster, You need to configure data and copies of each shard. One way is to use the monodump command to export data. Another method is to copy data files from one member of each shard, and then copy data files from another server.
Either way, make sure that no block is in the moving process when you back up the system again.
Stop the balancer: use config; db. setting. update ({_ id: "balancer" },{ $ set: {stopped: true}, true })
Re-confirm before backup: use config, db. locks. find ({"_ id": "balancer "})
Do not forget to start the balancer after the backup
Sh. setBalancerState ()
Sh. isBalancerRunning ()
VII. Failover and recovery
If a shard member fails, it is automatically transferred to another replica set member. If the performance is abnormal, restart mongos to reset it.
Configuration Server failure: a partition cluster generally has three configuration servers. If two servers fail, the remaining configuration servers become read-only, and all splitting and balancing operations will be stopped. This has no impact on the read/write operations of the Cluster. When the three configuration servers are restored, the server where the server is stopped will start to work again.
Mongos fault: If the mongos process fails, the application server is generally restarted;