Details
-
Bug
-
Status: Done
-
Medium
-
Resolution: Fixed
-
8.0.16-7
-
None
Description
Explicit encryption will still be used to mark tablespace as to be excluded from encryption threads. i.e. ALTER/CREATE TABLE/TABLESPACE ENCRYPTION=N will mean that table/tablespace should be excluded from encryption threads.
The information if table/tablespace is excluded from encryption threads will be visible through I_S table: INNODB_TABLESPACE_ENCRYPTION (which is current table used for showing information about tables encrypted by encryption threads). Due to changes in 8.0.16 we will no longer rely on SHOW CREATE TABLE to check if ENCRYPTION=’N’ was explicitly specified. Go to the bottom of this paragraph for explanation.
In MariaDB it is only possible to exclude innodb_file_per table tablespace. For us all tablespaces for which ALTER ENCRYPTION=N is possible should be excluded from encryption threads.
This approach will also solve the issue with upgrading from 5.7 to 8.0.16. The issue was that explicit encryption would need to be based on CREATE INFO flags from .frm file or crypt_data would need to be read before the upgrade. With INNODB_TABLESPACE_ENCRYPTION this will no longer be needed.
Prior to 8.0.16 only explicit ENCRYPTION=’N’ was visible in SHOW CREATE TABLE. After 8.0.16 no table/tablespace is allowed to have empty ENCRYPTON clause and from now on all unencrypted tables/tablespaces have ENCRYPTION=’N’ set. In SHOW CREATE TABLE ENCRYPTION=’N’ is only shown when encryption of table/tablespace is different from schema’s DEFAULT ENCRYPTION. i.e. DEFAULT_ENCRYPTION=Y. It is possible that implicit ENCRYPTION=’N’ will be seen in SHOW CREATE TABLE. Consider the scenario:
CREATE DATABASE db1 DEFAULT ENCRYPTION=’N’;
USE db1;
CREATE TABLE t1;
ALTER DATABASE db1 DEFAULT_ENCRYPTION=’Y’
SHOW CREATE TABLE t1 will show ENCRYPTION=’N’ although implicit encryption was used.
Attachments
Issue Links
- is blocked by
-
PS-5821 Revert explicit encryption from 8.0.16 added by PS-5772 8.0.16 encryption reconciliation
-
- Done
-