Академический Документы
Профессиональный Документы
Культура Документы
Okay, so you’ve read the first post on enabling MariaDB’s data at rest encryption, and now you are
ready to create an encrypted table.
And just to get it out of the way for those interested, you can always check your encrypted (and non-
encrypted) table stats via:
ENCRYPTION_SCHEME=1 means the table is encrypted and ENCRYPTION_SCHEME=0 means they are
not.
I find the following 4 tables interesting, as the first 3 essentially all create the same table, and the 4th
shows how to create a non-encrypted table once you have encryption enabled.
+-------+----------+-------------------+--------------------+-----------------+---------------------+--------------------------+-----
-------------------------+----------------+
+-------+----------+-------------------+--------------------+-----------------+---------------------+--------------------------+-----
-------------------------+----------------+
| 48 | dare/t10 | 1| 1| 1| 1| NULL |
NULL | 1|
| 49 | dare/t11 | 1| 1| 1| 1| NULL |
NULL | 1|
| 50 | dare/t13 | 0| 0| 0| 1| NULL |
NULL | 1|
| 51 | dare/t12 | 1| 1| 1| 1| NULL |
NULL | 18 |
+-------+----------+-------------------+--------------------+-----------------+---------------------+--------------------------+-----
-------------------------+----------------+
So when configuered as above, then we see t10, t11, and t12 were all encrypted no matter whether we
specified ENCRYPTED=YES in the CREATE TABLE. We also see t10 and t11 used KEY_ID #1 since we did
not specify ENCRYPTION_KEY_ID in the CREATE TABLE, whereas t12 did use KEY_ID #18 since we
specified ENCRYPTION_KEY_ID=18 in the CREATE TABLE.
We see that t13 was not encrypted, since we did specify ENCRYPTED=NO in the CREATE TABLE. This is
possible when you use innodb_file_per_table, the default.
If we attempt to create a table specifying ENCRYPTION_KEY_ID to a value that is not in the keys.txt file,
then you’ll see an error like the following:
ERROR 1005 (HY000): Can't create table `dare`.`t15` (errno: 140 "Wrong create options")
You will see the same if you try to ALTER an existing table from one ENCRYPTION_KEY_ID to another
that does not exist.
+----------+-------------------+
| NAME | ENCRYPTION_SCHEME |
+----------+-------------------+
| dare/t13 | 0|
+----------+-------------------+
+----------+-------------------+
| NAME | ENCRYPTION_SCHEME |
+----------+-------------------+
| dare/t13 | 1|
+----------+-------------------+
+----------+-------------------+
| NAME | ENCRYPTION_SCHEME |
+----------+-------------------+
| dare/t13 | 1|
+----------+-------------------+
+----------+-------------------+
| NAME | ENCRYPTION_SCHEME |
+----------+-------------------+
| dare/t13 | 0|
+----------+-------------------+
+----------+----------------+
| NAME | CURRENT_KEY_ID |
+----------+----------------+
| dare/t11 | 1|
+----------+----------------+
+----------+----------------+
| NAME | CURRENT_KEY_ID |
+----------+----------------+
| dare/t11 | 18 |
+----------+----------------+
Now change innodb-encrypt-tables=FORCE:
With this setting, if you attempt to create a table with ENCRYPTED=NO, then the command will fail:
ERROR 1005 (HY000): Can't create table `dare`.`t23` (errno: 140 "Wrong create options")
Similarly, if you attempt to change an encrypted table to a non-encrypted table with FORCE in effect,
you’ll see an error like the below:
ERROR 1005 (HY000): Can't create table `dare`.`#sql-29b4_2` (errno: 140 "Wrong create options")
Now revert the FORCE back to 1 for innodb-encrypt-tables, and drop innodb-encryption-threads from 4
to 0 because of high CPU usage issue – if you need to avoid it (and also revert innodb-encrypt-tables
back to 1 instead of FORCE)
+-------+----------+-------------------+--------------------+-----------------+---------------------+--------------------------+-----
-------------------------+----------------+
+-------+----------+-------------------+--------------------+-----------------+---------------------+--------------------------+-----
-------------------------+----------------+
| 63 | dare/t30 | 1| 1| 1| 1| NULL |
NULL | 1|
+-------+----------+-------------------+--------------------+-----------------+---------------------+--------------------------+-----
-------------------------+----------------+
I did this test since it could be necessary that to set innodb-encryption-threads=0 if the high CPU
utilzation issue requires you to do so, and you do not need the background threads to perform key
rotation (discussed more on the manual page listed above).
Also, I did this because I’ve heard that if you set innodb-encryption-threads=0, then newly created
tables where you do not explicitly set ENCRYPTED=YES will not be encrypted. I do not see that behavior,
as you can see above that the table is encrypted. So I do want to dispell this notion whilst I’m at it.
Misc:
I did notice that one you set an ENCRYPTION_KEY_ID for a table, it remains with that CREATE TABLE
output forever, even if you un-encrypt the table. Even an null ALTER TABLE does not remove it. It is
harmless, but soemthing to be aware of:
+---------+------+------------------------------------------------------------------+
+---------+------+------------------------------------------------------------------+
+---------+------+------------------------------------------------------------------+
+---------+------+------------------------------------------------------------------+
+---------+------+------------------------------------------------------------------+
+---------+------+------------------------------------------------------------------+
Table: t3
Lastly, I should mention that if you want to export a certain table to another instance, if it is encrypted,
it will not work as-is. You will need to un-encrypt the table first, then perform the discard/import
tablespace on the destination server, and then re-encrypt the table on the source server.
I hope this has helped covered the basics and a number of use cases to help you get your data at rest
encrypted.