Undo Log Encryption When  innodb_redo_log_encrypt  is enabled, unencrypted redo log pages that are present on disk remain unencrypted, and new redo log pages are written to disk in encrypted form. Likewise, when innodb_redo_log_encrypt  is disabled, encrypted redo log pages that are present on disk remain encrypted, and new redo log pages are written to disk in unencrypted form. Redo log encryption metadata, including the tablespace encryption key, is stored in the header of the first redo log file ( ib_logfile0 ). If this file is removed, redo log encryption is disabled. Once redo log encryption is enabled, a normal restart without the keyring component or plugin or without the encryption key is not possible, as  InnoDB  must be able to scan redo pages during startup, which is not possible if redo log pages are encrypted. Without the keyring component or plugin or the encryption key, only a forced startup without the redo logs ( SRV_FORCE_NO_LOG_REDO ) is possible. See Section 15.21.2, “Forcing InnoDB Recovery” . Undo log data encryption is enabled using the  innodb_undo_log_encrypt  configuration option. Undo log encryption applies to undo logs that reside in undo tablespaces. See Section 15.6.3.4, “Undo Tablespaces” . Undo log data encryption is disabled by default. As with tablespace data, undo log data encryption occurs when undo log data is written to disk, and decryption occurs when undo log data is read from disk. Once undo log data is read into memory, it is in unencrypted form. Undo log data is encrypted and decrypted using the tablespace encryption key. When  innodb_undo_log_encrypt  is enabled, unencrypted undo log pages that are present on disk remain unencrypted, and new undo log pages are written to disk in encrypted form. Likewise, when innodb_undo_log_encrypt  is disabled, encrypted undo log pages that are present on disk remain encrypted, and new undo log pages are written to disk in unencrypted form. Undo log encryption metadata, including the tablespace encryption key, is stored in the header of the undo log file. When undo log encryption is disabled, the server continues to require the keyring component or plugin that was used to encrypt undo log data until the undo tablespaces that contained the encrypted undo log data are truncated. (An encryption header is only removed from an undo tablespace when the undo tablespace is truncated.) For information about truncating undo tablespaces, see Truncating Undo Tablespaces. The master encryption key should be rotated periodically and whenever you suspect that the key has been compromised. Master key rotation is an atomic, instance-level operation. Each time the master encryption key is rotated, all tablespace keys in the MySQL instance are re-encrypted and saved back to their respective tablespace headers. As an atomic operation, re-encryption must succeed for all tablespace keys once a rotation operation is initiated. If master key rotation is interrupted by a server failure,  InnoDB  rolls the operation forward on server restart. For more information, see Encryption and Recovery. Rotating the master encryption key only changes the master encryption key and re-encrypts tablespace keys. It does not decrypt or re-encrypt associated tablespace data. Rotating the master encryption key requires the  ENCRYPTION_KEY_ADMIN  privilege (or the deprecated SUPER  privilege). 3201 Note Master Key Rotation Undo Log Encryption