As we have seen previously, usually MongoDB will adjust the bounds for each chunk in our shard to make sure that our data is equally distributed. This may not work in some cases, especially when we define the chunks manually, if our data distribution is surprisingly unbalanced, or if we have many delete operations in our shard.

Having empty chunks will invoke unnecessary chunk migrations and give MongoDB a false impression of which chunk needs to be migrated where. As we have explained before, the threshold for chunk migration is dependent on the number of chunks that each shard holds. Having empty chunks may or may not trigger the balancer when it's needed.

Chunk merging can only happen when at least one of the chunks is empty and only between neighboring chunks.

To find empty chunks, we need to connect to the database that we want to inspect (in our case, mongo_books) and do runCommand with dataSize set as follows:

> use mongo_books
> db.runCommand({
  "dataSize": "mongo_books.books",
  "keyPattern": { id: 1 },
  "min": { "id": -6 },
  "max": { "id": 0 }
})

dataSize follows the database_name.collection_name pattern, whereas keyPattern is the shard key that we have defined for this collection.

min and max values should be calculated by the chunks that we have in this collection. In our case, we entered ChunkB's details from the example earlier in this chapter.

If the bounds of our query (which, in our case, are the bounds of ChunkB) return no documents, the result will resemble the following:

{ "size" : 0, "numObjects" : 0, "millis" : 0, "ok" : 1 }

Now that we know that ChunkB has no data, we can merge it with another chunk (only ChunkA in the use case described before) like this:

> db.runCommand( { mergeChunks: "mongo_books.books",
                bounds: [ { "id": -12 },
                          { id: 0 } ]
            } )

On success, this will return MongoDB's default ok status message:

{ "ok" : 1 }

We can then verify that we only have one chunk on ShardA by invoking sh.status() again.