[SERVER-53683] Await configRS optime replication before stopping replication in refine_collection_shard_key_abort_on_stepup.js Created: 11/Jan/21 Updated: 29/Oct/23 Resolved: 13/Jan/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 4.9 Required |
| Fix Version/s: | 4.9.0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jordi Serra Torrens | Assignee: | Jordi Serra Torrens |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Sprint: | Sharding 2021-01-25 | ||||
| Participants: | |||||
| Linked BF Score: | 14 | ||||
| Description |
|
In order to perform this refineCollectionShardKey, the shard will try to refresh the collection information from the configsvr using majority read concern and nearest preference. This could fail if the shard tries to refresh from the configsvr secondary that has replication stopped, as it could not satisfy the read concern. Currently the refine_collection_shard_key_abort_on_stepup.js test is only awaiting replication before sharding the collection. Later the collection is sharded and then replication stops on the configsvr secondary, with may not have replicated it. The proposal is to introduce an awaitReplication() call after the shardCollection. |
| Comments |
| Comment by Githook User [ 12/Jan/21 ] |
|
Author: {'name': 'Jordi Serra Torrens', 'email': 'jordi.serra-torrens@mongodb.com', 'username': 'jordist'}Message: |
| Comment by Githook User [ 11/Jan/21 ] |
|
Author: {'name': 'Jordi Serra Torrens', 'email': 'jordi.serra-torrens@mongodb.com', 'username': 'jordist'}Message: |