Encrypting Binary Log Files and Relay Log Files •Data at rest that is written to the binary log files and relay log files is encrypted from the point in time where encryption is started, using the two tier encryption architecture described above. Existing binary log files and relay log files that were present on the server when you started encryption are not encrypted. You can purge these files when they are no longer needed. •Data in motion in the replication event stream, which is sent to MySQL clients including  mysqlbinlog , is decrypted for transmission, and should therefore be protected in transit by the use of connection encryption (see Section 6.3, “Using Encrypted Connections”  and Section 17.3.1, “Setting Up Replication to Use Encrypted Connections” ). •Data in use that is held in the binary log transaction and statement caches during a transaction is in unencrypted format in the memory buffer that stores the cache. The data is written to a temporary file on disk if it exceeds the space available in the memory buffer. From MySQL 8.0.17, when binary log encryption is active on the server, temporary files used to hold the binary log cache are encrypted using AES-CTR (AES Counter mode) for stream encryption. Because the temporary files are volatile and tied to a single process, they are encrypted using single-tier encryption, using a randomly generated file password and initialization vector that exist only in memory and are never stored on disk or in the keyring. After each transaction is committed, the binary log cache is reset: the memory buffer is cleared, any temporary file used to hold the binary log cache is truncated, and a new file password and initialization vector are randomly generated for use with the next transaction. This reset also takes place when the server is restarted after a normal shutdown or an unexpected halt. 3619 {UUID}  is the true UUID generated by the MySQL server (the value of the  server_uuid  system variable).  {SEQ_NO}  is the sequence number for the binary log encryption key, which is incremented by 1 for each new key that is generated on the server. The format of binary log encryption keys in the keyring is as follows: The binary log encryption keys for a MySQL server instance must be included in your backup and recovery procedures, because if the keys required to decrypt the file passwords for current and retained binary log files or relay log files are lost, it might not be possible to start the server. The binary log encryption keys used to encrypt the file passwords for the log files are 256-bit keys that are generated specifically for each MySQL server instance using MySQL Server’s keyring service (see Section 6.4.4, “The MySQL Keyring” ). The keyring service handles the creation, retrieval, and deletion of the binary log encryption keys. A server instance only creates and removes keys generated for itself, but it can read keys generated for other instances if they are stored in the keyring, as in the case of a server instance that has been cloned by file copying. If you use  LOAD DATA  when  binlog_format=STATEMENT  is set, which is not recommended as the statement is considered unsafe for statement-based replication, a temporary file containing the data is created on the replica where the changes are applied. These temporary files are not encrypted when binary log encryption is active on the server. Use row-based or mixed binary logging format instead, which do not create the temporary files. Note 17.3.2.2 Binary Log Encryption Keys Important For example: MySQLReplicationKey_{UUID}_{SEQ_NO} MySQLReplicationKey_00508583-b5ce-11e8-a6a5-0010e0734796_1 