ISSUE DESCRIPTION AND IMPACT
If a user specifies zones for a non-empty collection prior to sharding it, there is a chance that the initial chunk will be placed onto an incorrect shard, thus effectively losing all the documents in the sharded collection. This will occur if there is more than one shard (e.g. shard01, shard02) and the database's primary is not the first alphabetically-sorted shard (e.g. shard02 in the example above).
DIAGNOSIS AND AFFECTED VERSIONS
Only MongoDB 4.0.5 is affected. Prior to MongoDB 4.0.5, it was not possible to shard a non-empty collection with zones preset.
REMEDIATION AND WORKAROUNDS
Users running MongoDB 4.0.5 are strongly encouraged to upgrade to 4.0.6 or later immediately. If an immediate upgrade is not possible, users should ensure that no zones are set for a non-empty collection before sharding it. After sharding a non-empty collection, the zones can be safely set.
FIXED VERSIONS
The fix is included in MongoDB 4.0.6.
Original description
When sharding a non-empty collection, whose primary is not the first alphabetically-sorted shard, the Fast Initial Split logic can select wrong shard for the lone initial chunk.
These are the conditions for this issue to occur:
- There is more than one shard (e.g., shard01, shard02)
- The database's primary is not the first alphabetically-sorted shard (shard02 in the example above)
- There are some zones defined for the collection (so the Fast Initial Split optimization is attempted)
- The unsharded collection contains some documents (so that the Fast Initial Split optimization won't kick-in)
In this case, attempting to shard such a collection will wrongly place the only chunk on the first alphabetically-sorted shard, which means none of the documents for that collection will be visible anymore.