[SERVER-24527] add test to ensure shard undergoes sharding initialization through setShardVersion Created: 10/Jun/16 Updated: 19/Nov/16 Resolved: 19/Sep/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.3.14 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Esha Maharishi (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Sharding 2016-08-29, Sharding 2016-09-19, Sharding 2016-10-10 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
The test sharding_state_after_stepdown.js was deleted as part of However, some parts of the test regarding loading sharding metadata should be re-added as a new test (unless there are sufficient existing tests around sharding metadata initialization). |
| Comments |
| Comment by Githook User [ 19/Sep/16 ] |
|
Author: {u'name': u'Esha Maharishi', u'email': u'esha.maharishi@mongodb.com'}Message: |
| Comment by Esha Maharishi (Inactive) [ 16/Sep/16 ] |
|
For context: The original test utilized mongos to check that sharding initialization through setShardVersion happened by asserting that shards targeted for a query or command became sharding aware. However, after the original test was deleted, a change in the balancer logic made the balancer send a sharded command to every shard every 10 seconds, so setShardVersion is now sent from the balancer as well: Thus, the new test simply expects the balancer to send setShardVersion and for newly added shards to undergo sharding initialization soon, even if they don't receive a shardIdentity document. |
| Comment by Esha Maharishi (Inactive) [ 07/Sep/16 ] |
|
Related to The removed test checks that setShardVersion is appropriately sent to a shard after the shard is hit by a sharded query, and that sharding state is then initialized on the shard. The test assumes that restarting or stepping down a shard primary will clear its sharding state. However, after All Nodes Shard Aware: 1) the shard will remember its sharding state after a restart through the on-disk shardIdentity doc The only period that shard aware initialization is still performed through setShardVersion is: 1) if a 3.2 mongos adds a shard, and the mongos sends setShardVersion to the new shard before the config asynchronously inserts the shardIdentity document on the new shard Therefore, a failpoint that stops or delays the shardIdentity document from being sent from the config to the new shard is probably useful for both tests. |