MongoDB practice (11) Sharding fragmentation (part two)

Management Maintenance Sharding

List all Shard Servers

View Sharding information

Decide if it is Sharding.

Sharding an existing table

Just now we fragmented the table test.users. Next we will fragment the existing unfragmented table test.users_2 in the library.

line fragmentation

The initial state of the table is as follows, and it can be seen that it has not been fragmented:

To fragment it:

Looking again at the state of the table after fragmentation, you can see that it has been fragmented by us

Added Shard Server

Just now we demonstrated how to add a shard table. Next we demonstrate how to add a Shard Server.

Start a new Shard Server process

Configure the new Shard Server

Check the shard table status to verify the new Shard Server

We can see that when we add Shard Server, the data is automatically distributed to the new Shard, which is created by MongoDB.

internally self-fulfilling.

Remove Shard Server

Sometimes there are limited hardware resources, so we have to do some recycling work, and now we will just enable

Shard Server recovery, the system will first be removed on the Shard Server data will be evenly distributed

to other Shard Servers, and then finally kick this Shard Server offline, we need to keep calling

db.runCommand({"removeshard" : "localhost:20002"}); to see where the removal operation goes:

After the final removal, when we call db.runCommand({"removeshard" : "localhost:20002"}) again the system

An error will be reported informing us that there is no Shard Server for port 20002 because it has been removed.

Let's look at the distribution of data in the table:

It can be seen that the data is evenly distributed to the other two Shard Servers, which has no significant impact on the business.

But why does the node still exist, leaving a question???