Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Not a Bug
-
Affects Version/s: 10.1.7
-
Fix Version/s: N/A
-
Component/s: Documentation
-
Labels:None
Description
Documentation does not show anything about needing to recreate the redo log.
I believe it should be at least recommended if it is not needed, assuming the server doesn't do it automatically.
Gliffy Diagrams
Attachments
Issue Links
- is part of
-
-
- Open
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Idea is that you enable encryption before you start creating data that needs encryption. Currently, tablespace encryption allows to encrypt tables that were created before enabling encryption. However, similar functionality is not available for log files. So this it up to user, either log files can be recreated (if needed) or not. Currently, we do not have plans to extent background encryption to log files.
On one hand, I don't see why it needs to be needed. The use case is that earlier the user was fine with the log not being encrypted; then encryption was switched on, and new contents started getting encrypted. The old contents, which was not encrypted before, remained as it was.
I would rather say recreating is needed when one switches from encrypted to non-encrypted log, because the data that the user bothered to encrypt before (and probably hoped to keep encrypted) might suddenly become visible.
But on the other hand, this request somewhat suits the logic of innodb_encrypt_tables – if turning it on makes already existing tables get encrypted, maybe it should be similar with innodb_encrypt_log.
Assigning to Jan Lindström to decide, I won't mind it to be either way.