Encryption and Recovery To rotate the master encryption key, run: mysql>  ALTER INSTANCE ROTATE INNODB MASTER KEY; ALTER INSTANCE ROTATE INNODB MASTER KEY  supports concurrent DML. However, it cannot be run concurrently with tablespace encryption operations, and locks are taken to prevent conflicts that could arise from concurrent execution. If an  ALTER INSTANCE ROTATE INNODB MASTER KEY  operation is running, it must finish before a tablespace encryption operation can proceed, and vice versa. If a server failure occurs during an encryption operation, the operation is rolled forward when the server is restarted. For general tablespaces, the encryption operation is resumed in a background thread from the last processed page. The keyring component or plugin must be loaded prior to storage engine initialization so that the information necessary to decrypt tablespace data pages can be retrieved from tablespace headers before InnoDB  initialization and recovery activities access tablespace data. (See Encryption Prerequisites.) If a server failure occurs during master key rotation,  InnoDB  continues the operation on server restart. When  InnoDB  initialization and recovery begin, the master key rotation operation resumes. Due to the server failure, some tablespace keys may already be encrypted using the new master encryption key.  InnoDB  reads the encryption data from each tablespace header, and if the data indicates that the tablespace key is encrypted using the old master encryption key,  InnoDB  retrieves the old key from the keyring and uses it to decrypt the tablespace key.  InnoDB  then re-encrypts the tablespace key using the new master encryption key and saves the re-encrypted tablespace key back to the tablespace header. Tablespace export is only supported for file-per-table tablespaces. When an encrypted tablespace is exported,  InnoDB  generates a  transfer key  that is used to encrypt the tablespace key. The encrypted tablespace key and transfer key are stored in a  tablespace_name .cfp file. This file together with the encrypted tablespace file is required to perform an import operation. On import,  InnoDB  uses the transfer key to decrypt the tablespace key in the  tablespace_name .cfp  file. For related information, see Section 15.6.1.3, “Importing InnoDB Tables” . 3202 Encryption and Recovery Exporting Encrypted Tablespaces Encryption and Replication •The  ALTER INSTANCE ROTATE INNODB MASTER KEY  statement is only supported in replication environments where the source and replica run a version of MySQL that supports tablespace encryption. •Successful  ALTER INSTANCE ROTATE INNODB MASTER KEY  statements are written to the binary log for replication on replicas. •If an  ALTER INSTANCE ROTATE INNODB MASTER KEY  statement fails, it is not logged to the binary log and is not replicated on replicas. •Replication of an  ALTER INSTANCE ROTATE INNODB MASTER KEY  operation fails if the keyring component or plugin is installed on the source but not on the replica. •If the  keyring_file  or  keyring_encrypted_file  plugin is installed on both the source and a replica but the replica does not have a keyring data file, the replicated  ALTER INSTANCE ROTATE INNODB MASTER KEY  statement creates the keyring data file on the replica, assuming the keyring file data is not cached in memory.  ALTER INSTANCE ROTATE INNODB MASTER KEY  uses keyring file data that is cached in memory, if available.