redo log encryption fails to error out even if keyring plugin configuration is missing

Description

  • Create seed database w/o any encryption

  • Start ps instance with redo log encryption (w/o specifying keyring plugin params).

  • Expected: Error out as set innodb_redo_log_encrypt to 0 as done by upstream (mysql)

mysql> select @@innodb_redo_log_encrypt;

---------------------------

@@innodb_redo_log_encrypt

---------------------------

0

---------------------------
1 row in set (0.00 sec)
2019-03-12T09:10:06.911664Z 0 [ERROR] [MY-012661] [InnoDB] Encryption can't find master key, please check the keyring plugin is loaded.
2019-03-12T09:10:06.911718Z 0 [ERROR] [MY-013068] [InnoDB] Can't set redo log tablespace to be encrypted.

 

  • PS allows the server to boot doesn't throw any error and doesn't even set innodb_redo_log_encrypt = 0. This is not true since w/o keyring how can PS encrypt the said redo log space. Where does it store/caches the key.

  • Now if we specify innodb_log_file_size=XM (something > default) that would cause the creation of InnoDB log file this would error out but the default file doesn't.

 

 

Environment

None

Smart Checklist

Activity

Show:

C W May 7, 2019 at 12:39 PM

OK, I see that you are reporting something slightly different, it wasn't so clear without specific steps.

It doesn't happen when using SET PERIST

However, I do see it with what I presume you are referring to:

Krunal Bauskar May 7, 2019 at 2:34 AM

Can you try with the said step (mentioned above)? I see your upstream issue but there you seem to be setting the variable dynamically.

(When I logged it I observed MySQL used to error out during the start of the server if it failed to encrypt redo due to the absence of keyring).

C W May 6, 2019 at 2:08 PM
Edited

I believe that this is an upstream bug. However, does appear to be a difference in implementation

Done

Details

Assignee

Reporter

Time tracking

1w 2h 10m logged

Fix versions

Priority

Smart Checklist

Created March 12, 2019 at 11:18 AM
Updated March 6, 2024 at 12:17 PM
Resolved May 29, 2019 at 6:45 AM