[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:
Related
is related to SERVER-24126 Add step to _cfgsvrAddShard command w... Closed
is related to SERVER-25971 Test performing ops against a 3.4 sha... Closed
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 SERVER-24126 since the changes in that ticket make shard nodes shard aware on (re)start.

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: SERVER-24527 add test to ensure shard undergoes sharding initialization through setShardVersion
Branch: master
https://github.com/mongodb/mongo/commit/fd19ddff758912365f22813d2ec8c93688676144

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:
https://github.com/mongodb/mongo/commit/89bc462da9bd7c5edd6c54da58615a0cc8542ebd#diff-e080c2c67c95e7f7f98e8655372b9996R556
followed by:
https://github.com/mongodb/mongo/commit/7f736859d32f9237aa382a676644082a9f66a45d#diff-e080c2c67c95e7f7f98e8655372b9996R431

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 SERVER-25971:

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
2) secondaries are also shard aware

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
2) if a 3.4 mongos adds a shard, and the mongos sends setShardVersion to the new shard before the asynchronous OpObserver on the shard finishes sharding initialization

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.

Generated at Thu Feb 08 04:06:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.