ISSUE SUMMARY
On tag-aware sharded clusters, when the balancer is active and the top/bottom chunk needs to be split, the new chunk may be temporarily moved to a shard with an incompatible tag thus temporarily violating tagging.
This issue does not apply to sharded clusters using hashed shard keys.
USER IMPACT
Users with a heavy insert load may experience poor performance due to unneccessary migrations.
WORKAROUNDS
Users may consider adding a split point at an extremely high, unreachable shard key to prevent this behavior.
AFFECTED VERSIONS
MongoDB production releases up to 2.6.5 are affected by this issue.
FIX VERSION
The fix is included in the 2.6.6 production release.
Original description
In special logic for splitting top or bottom chunk https://github.com/mongodb/mongo/blob/master/src/mongo/s/d_split.cpp#L886 sets shouldMigrate to true.
https://github.com/mongodb/mongo/blob/master/src/mongo/s/chunk.cpp#L466 goes along with the idea as long as balancing isn't disabled, and uses Shard::pick() to find the new target shard for the "hot" chunk.
However, https://github.com/mongodb/mongo/blob/master/src/mongo/s/shard.cpp#L425 does not seem to take tags into account and ends up moving the chunk to a shard from which it must then immediately be moved in the next round (violating tagging in the meanwhile).
This problem does not apply to hashed shard key since special logic is bypassed in that case.
- depends on
-
SERVER-14667 mongos does not move top chunk after auto-split
- Closed
- is duplicated by
-
SERVER-4687 need to check draining and potentially other shard status before auto-migrates
- Closed
- related to
-
SERVER-18361 Sharding "top" splits should respect tag boundaries
- Closed
- tested by
-
SERVER-15831 Enhanced top chunk auto split tests
- Closed