[SERVER-28883] Avoid the scenario when KeyManager creates 2 keys with close expiration Created: 20/Apr/17  Updated: 29/Jan/18  Resolved: 13/Jun/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.5.6
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Misha Tyulenev Assignee: Misha Tyulenev
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-28972 Relax KeysCollectionManager::getKeyFo... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2017-06-19
Participants:

 Description   

Imagine the scenario of the node1 that is a primary becomes secondary while the node2 becomes a new primary. If the key expiration coincides with the transition its possible that
node1 writes a new key just before it stops being primary and node2 reads the stale cache and adds another key. As a result the system.keys collection will have two different keys with the close expiresAt values. This can lead to the scenario when the key is not available to a secondary when 2 keys with close expiration just expired but the new key is not added by a KeyUpdater because the node has a clock skew.



 Comments   
Comment by Misha Tyulenev [ 13/Jun/17 ]

The fix for SERVER-28972 will make this scenario unfeasible.

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