[MDEV-8885] Documentation does not have instructions Created: 2015-10-02  Updated: 2015-10-05  Resolved: 2015-10-05

Status: Closed
Project: MariaDB Server
Component/s: Documentation
Affects Version/s: 10.1.7
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Michaël de groot Assignee: Jan Lindström (Inactive)
Resolution: Not a Bug Votes: 0
Labels: None

Issue Links:
PartOf
is part of MDEV-8884 InnoDB redo log encryption not workin... Closed

 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.



 Comments   
Comment by Elena Stepanova [ 2015-10-03 ]

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 jplindst to decide, I won't mind it to be either way.

Comment by Jan Lindström (Inactive) [ 2015-10-05 ]

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.

Generated at Thu Feb 08 07:30:31 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.