Enabling and Troubleshooting MySQL InnoDB REDO Log Archiving

The REDO log archiving feature was introduced in MySQL 8.0.17 to prevent backup tools such as mysqlbackup and xtrabackup from falling behind the rate at which the server generates REDO logs, which could otherwise cause data inconsistency.

Enabling the feature is straightforward: set the innodb_redo_log_archive_dirs system variable to a label and a target directory.

set persist innodb_redo_log_archive_dirs='redo_archive1:/redo_mysql/3306'

The label (e.g., redo_archive1 ) can be any name, while the path specifies where archived REDO logs will be stored.

Common pitfalls and their fixes

1. Directory existence and permissions

If the archive directory does not exist or lacks proper ownership, MySQL reports:

ERROR 3844 (HY000): Redo log archive directory '/redo_mysql/3306' does not exist or is not a directory

Create the directory and restrict access to the OS user that runs MySQL:

# Create the directory
mkdir -p /redo_mysql/3306
# Restrict permissions to owner only
chmod -R 700 /redo_mysql/3306/

Then set the variable with a user that has SYSTEM_VARIABLES_ADMIN privilege:

# Set variable
set persist innodb_redo_log_archive_dirs='redo_archive1:/redo_mysql/3306';
# Verify
show variables like 'innodb_redo_log_archive_dirs';
+------------------------------+--------------------------------+
| Variable_name                | Value                         |
+------------------------------+--------------------------------+
| innodb_redo_log_archive_dirs | redo_archive1:/redo_mysql/3306 |
+------------------------------+--------------------------------+

2. Backup tool warnings

Running mysqlbackup after the above setup may still produce a warning if the backup process runs under a different OS user without write permission to the archive directory:

WARNING: MySQL query 'DO innodb_redo_log_archive_start('redo_archive1','16800686281315958');': 3844, Redo log archive directory '/redo_mysql/3306/16800686281315958' does not exist or is not a directory

Identify the MySQL process owner (e.g., ytt ) and grant the directory to that user:

# Check MySQL OS user
ps aux | grep mysqld
# Change ownership
chown -R ytt.ytt /redo_mysql

After fixing permissions, re‑run the backup as the correct OS user:

# Switch to the proper user
su ytt
# Run backup again
mysqlbackup --defaults-file=/etc/my.cnf --defaults-group-suffix=@3306 \
    --login-path=backup_pass2 --backup-dir=/tmp/full backup
# Expected output: backup completed OK! with no warnings

3. Required MySQL privileges

The backup user must be granted the INNODB_REDO_LOG_ARCHIVE privilege (along with other backup‑related privileges):

show grants for backup_user2\G
... 
GRANT BACKUP_ADMIN, ENCRYPTION_KEY_ADMIN, INNODB_REDO_LOG_ARCHIVE, SYSTEM_VARIABLES_ADMIN ON *.* TO `backup_user2`@`%`;
...

4. Manual archiving via the client

REDO log archiving can also be started directly from the MySQL client using the DO statement:

DO innodb_redo_log_archive_start('redo_archive1','20230329');
Query OK, 0 rows affected (0.02 sec)

The corresponding archive files appear under the configured directory, and their size grows as more data is generated (e.g., from 4 KB to 128 MB).

5. Operational notes

The session that issued innodb_redo_log_archive_start must remain open; closing it stops archiving.

The archive directory must not be part of MySQL's own data directories (e.g., datadir or innodb_directories ).

Following these steps ensures reliable REDO log archiving, preventing backup inconsistencies and enabling efficient point‑in‑time recovery.