[SERVER-47568] No keys found for HMAC in RECOVERING state Created: 15/Apr/20 Updated: 29/Oct/23 Resolved: 04/May/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.6.17, 4.2.5, 4.0.18 |
| Fix Version/s: | 4.2.13, 4.4.5, 4.0.24, 5.0.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Misha Tyulenev | Assignee: | Jack Mulrow |
| Resolution: | Fixed | Votes: | 4 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||
| Backport Requested: |
v4.2, v4.0
|
||||||||||||||||||||||||||||
| Sprint: | Sharding 2020-09-07, Sharding 2021-01-11, Sharding 2021-01-25, Sharding 2021-02-22, Sharding 2021-03-08, Sharding 2021-03-22, Sharding 2021-04-05, Sharding 2021-04-19, Sharding 2021-05-03, Sharding 2021-05-17 | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||
| Linked BF Score: | 142 | ||||||||||||||||||||||||||||
| Description |
|
Cluster time validation reads signing keys from cache , and if there are no keys the cache is refreshed by reading admin.system.keys collection. When the server is in the RECOVERING state it can not read from any collection including admin.system.keys collection. Hence any request, in particular isMaster from a monitoring agent returns meesages similar to
|
| Comments |
| Comment by Githook User [ 04/May/21 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: |
| Comment by Githook User [ 11/Mar/21 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: |
| Comment by Githook User [ 09/Mar/21 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: |
| Comment by Githook User [ 04/Mar/21 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: (cherry picked from commit 024b130c5e66bafd99cf7f899cdef8d23284ef81) |
| Comment by Githook User [ 04/Mar/21 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: (cherry picked from commit 024b130c5e66bafd99cf7f899cdef8d23284ef81) |
| Comment by Githook User [ 03/Mar/21 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: |
| Comment by Githook User [ 05/Aug/20 ] |
|
Author: {'name': 'Misha Tyulenev', 'email': 'misha.tyulenev@mongodb.com'}Message: Revert " This reverts commit 3c9d3a05755057791a045214b2580e7074291ef6. |
| Comment by Githook User [ 04/Aug/20 ] |
|
Author: {'name': 'Misha Tyulenev', 'email': 'misha.tyulenev@mongodb.com'}Message: |
| Comment by Misha Tyulenev [ 29/Jul/20 ] |
|
Note: after the fix its possible to get the InvalidOptions error when processing atClusterTime or afterClusterTime on a non readable node due to the check for atClusterTime or afterClusterTime to be greater than the current node's clusterTime. |
| Comment by Kostiantyn Dobarskyi [ 27/Jul/20 ] |
|
I see exactly the same exceptions reported by Mongo driver connected to an Atlas replica set (version 4.0.19) while cluster maintenance is in progress. |
| Comment by Misha Tyulenev [ 04/Jun/20 ] |
|
Implemented a fix, but could not reproduce the scenario in a testcase. Back to the HELP ticket scenario to find out the exact scenario. |