[SERVER-30329] WiredTiger encryption at rest downgrade path from 3.6 -> 3.4 Created: 25/Jul/17 Updated: 30/Oct/23 Resolved: 27/Jul/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security, Storage |
| Affects Version/s: | None |
| Fix Version/s: | 3.5.11 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Daniel Gottlieb (Inactive) | Assignee: | Daniel Gottlieb (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Storage 2017-07-31 |
| Participants: |
| Description |
|
Encryption at rest uses a second WiredTiger database to store encryption keys to the standard MongoDB databases. Without modification, the wiredtiger_open call of this second database in 3.6 will upgrade WT's file compatibility to 3.0. A shutdown on FCV 3.4 would require changing the compatibility back to 2.9. One option is to never upgrade this inner wiredtiger instance to 3.0 and keep it on 2.9. The bug fixed in WT's journal is unlikely to happen on this keystore database. Alternatively, this keystore could run in "no journal" mode and require a checkpoint to make writes durable. Another edge case to consider is that key rotation does an early shutdown of the `mongod` process. This happens before the FCV value is read from the `admin.system.version` collection. This leaves storage engine cleanup in a state where it does not know what version the file compatibility should be set to. It may make sense for key rotation to always use file compatibility 2.9. Alternatively WiredTiger can expose a method for keeping the file compatibility the same instead of auto-upgrading. |
| Comments |
| Comment by Githook User [ 27/Jul/17 ] |
|
Author: {'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb', 'name': 'Daniel Gottlieb'}Message: |
| Comment by Githook User [ 27/Jul/17 ] |
|
Author: {'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb', 'name': 'Daniel Gottlieb'}Message: |
| Comment by Daniel Gottlieb (Inactive) [ 26/Jul/17 ] |
|
Great, I think using the 2.9 compatibility flag is a winner. spencer.jackson Just tagging you to see a correction from my assessment. The 2.9 file compatibility no longer has the journaling bug in WiredTiger, just a sub-optimal solution. |
| Comment by Susan LoVerso [ 26/Jul/17 ] |
FTR, the bug in the journal is fixed in the latest release of 3.4, it just uses an fsync call so the log file format change in WT is performance related not correctness related. So staying at 2.9 is viable. Then when the users will no longer (potentially) run at that release the option can be removed.
This is also a viable option. Yes, these updates would have to be durable after every write. But this database should rarely be written. Both options appear low-risk and small changes. I think that passing in the 2.9 compatibility flag is a smaller change and solves the problem. |