[SERVER-83699] Investigate possible race between the EncryptionKeyManager and background compaction Created: 28/Nov/23  Updated: 11/Dec/23  Resolved: 11/Dec/23

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

Type: Task Priority: Major - P3
Reporter: Etienne Petrel Assignee: Gregory Wlodarek
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to WT-11678 Investigate issues generated by backg... Closed
Assigned Teams:
Storage Execution
Sprint: Execution Team 2023-12-25
Participants:
Story Points: 5

 Description   

In WT-11678, we faced failures where background compaction interacted with the EncryptionKeyManager during shutdown while the EncryptionKeyManager objects had already been freed. This ticket should investigate the race and check if synchronisation should be put in place.



 Comments   
Comment by Gregory Wlodarek [ 11/Dec/23 ]

The issue here is that in testing we started background compaction on the (main) encrypted database before the (second) WiredTiger instance that encrypts/decrypts pages was started. This should no longer be an issue after SERVER-83734, where we changed background compaction to start once mongod startup is finished.

Comment by Etienne Petrel [ 30/Nov/23 ]

That's perfectly fine, steven.vannelli@mongodb.com, thank you for following up!

Comment by Etienne Petrel [ 28/Nov/23 ]

Initial analysis can be found here and here.

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