[SERVER-54205] [causal consistency] Proactively load external keys into the keys cache on secondaries Created: 02/Feb/21 Updated: 29/Oct/23 Resolved: 22/Feb/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.9.0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Jack Mulrow |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | pm-1791_alpha2, pm-1791_milestone-F | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Sprint: | Sharding 2021-02-22, Sharding 2021-03-08 | ||||
| Participants: | |||||
| Description |
|
Currently, the key manager is proactively refreshed on tenant migration donor and recipient primaries. This avoids having to check for new external keys every time a signed cluster time is received (note this is not just when an unrecognized keyId is seen because keyIds may be the same for internal and external keys). Similarly, secondaries for both replica sets will need to proactively cache these external keys at some point before the migration commits, otherwise they will be unable to validate signatures from the other after the migration cutover. |
| Comments |
| Comment by Githook User [ 08/Mar/21 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: |
| Comment by Githook User [ 22/Feb/21 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: |