In Percona Server5.7.20-18 existing tablespace encryption support
has been extended to handle general tablespaces. A general tablespace is either
fully encrypted, covering all the tables inside, either not encrypted at all.
It is not possible to have only some of the tables in the general tablespace
encrypted.

This feature extends the CREATE TABLESPACE
statement to accept the ENCRYPTION='Y/N' option.

General tablespace encryption is enabled by the following syntax extension:

mysql>CREATETABLESPACEtablespace_name...ENCRYPTION='Y'

Attempts to create or to move tables, including partitioned ones, to a general
tablespace with an incompatible encryption setting are diagnosed and aborted.

As you cannot move tables between encrypted and unencrypted tablespaces,
you will need to create another table, add it to a specific tablespace and run
INSERTINTOSELECT from the table you want to move from, and then you will
get encrypted or decrypted table with your desired content.

While replicating, master sends the stream of decrypted binary log events to a
slave (SSL connections can be set up to encrypt them in transport). That said,
masters and slaves use separate keyring storages and are free to use differing
keyring plugins.

Dumping of encrypted binary logs involves decryption, and can be done using
mysqlbinlog with --read-from-remote-server option.

Note

Taking into account that --read-from-remote-server option is only
relevant to binary logs, encrypted relay logs can not be dumped/decrypted
in this way.

It should be loaded this way to be able to facilitate recovery for encrypted
tables.

Warning

If server should be started with several plugins loaded early,
--early-plugin-load should contain their list separated by semicolons. Also
it’s a good practice to put this list in double quotes so that semicolons
do not create problems when executed in a script.

Apart from installing plugin you also need to set the
keyring_vault_config variable. This variable should point to the
keyring_vault configuration file, whose contents are discussed below.

On plugin initialization keyring_vault connects to the Vault server using
credentials stored in the credentials file. Location of this file is specified
in by keyring_vault_config. On successful initialization it
retrieves keys signatures and stores them inside an in-memory hash map.

Configuration file should contain the following information:

vault_url - the address of the server where Vault is running. It can be a
named address, like one in the following example, or just an IP address. The
important part is that it should begin with https://.

secret_mount_point - the name of the mount point where keyring_vault
will store keys.

token - a token generated by the Vault server, which keyring_vault
will further use when connecting to the Vault. At minimum, this token should
be allowed to store new keys in a secret mount point (when keyring_vault
is used only for transparent data encryption, and not for keyring_udf
plugin). If keyring_udf plugin is combined with keyring_vault, this
token should be also allowed to remove keys from the Vault (for the
keyring_key_remove operation supported by the keyring_udf plugin).

vault_ca[optional] - this variable needs to be specified only when the
Vault’s CA certificate is not trusted by the machine that is going to connect
to the Vault server. In this case this variable should point to CA
certificate that was used to sign Vault’s certificates.

When a key is fetched from a keyring for the first time the
keyring_vault communicates with the Vault server, and retrieves the key
type and data. Next it queries the Vault server for the key type and data and
caches it locally.

Key deletion will permanently delete key from the in-memory hash map and the
Vault server.

This variable allows to set the duration in seconds for the Vault server
connection timeout. Default value is 15. Allowed range is from 1
second to 86400 seconds (24 hours). The timeout can be also completely
disabled by setting this variable to 0.