--innodb_data_file_path

--innodb_log_files_in_group

--innodb_log_file_size

--innodb_page_size

--innodb_checksum_algorithm

--keyring_file_data

--keyring_okv_conf_dir

--relay-log-info-file

--master-info-file

--backup_innodb_log_files_in_group

--backup_innodb_log_file_size

--backup_innodb_undo_tablespaces

--backup_innodb_undo_logs

--backup_innodb_page_size

--backup_innodb_checksum_algorithm

When working with a Group Replication setup, mysqlbackup now makes the backup history available to all members of the server group by making sure that the backup_history table is updated on a primary node after each mysqlbackup operation. See Chapter 9, Using MySQL Enterprise Backup with Group Replication for details, including the resulting new user privilege requirement for mysqlbackup to connect to a server, regardless of whether the server belongs to a Group Replication setup.

The storage engine of the mysql.backup_history table on a backed-up server has switched from CSV to InnoDB. See here for the special user privileges now required by mysqlbackup that are related to this change.

mysqlbackup now supports transparent page compression for InnoDB tables. The support is enabled by setting the mysqlbackup option --compress-method=punch-hole; see description for the option for details.

mysqlbackup now supports backup compression (i.e., the use of the --compress and --uncompress options) for incremental backups (except for incremental backups created with the --incremental-with-redo-log-only option).

mysqlbackup now supports the --ssl-fips-mode option, which controls whether mysqlbackup operates in FIPS mode. See FIPS Support for details.

mysqlbackup now supports encrypted binary and relay log. See Section 8.4, “Working with Encrypted Binary and Relay Logs” for details.

Near the end of the backup process, instead of locking the whole server instance for a brief period of time, mysqlbackup now applies these locks consecutively:

See Section 1.4, “The Backup Process” for details. The removal of the lock on the whole server instance reduces disruption to the database service by the backup operation.

In addition to the requirement that the target data directory for a restore specified by --datadir must be non-existent or empty, mysqlbackup now enforces the same rule for the --innodb_data_home_dir, --innodb_log_group_home_dir, and --innodb_undo_directory options (the --force option cannot be used to override the requirement on the three options).

mysqlbackup now supports dynamic changes to undo tablespaces on the server being backed up. During a restore, the default undo tablespaces, as well as any non-default undo tablespaces resided in the backed-up server's data directory, are restored to the location pointed to by the mysqlbackup option innodb_undo_directory. Non-default, external undo tablespaces are restored to the locations they were found on the backed-up server. See descriptions for the undo log files for details.

mysqlbackup now supports encrypted InnoDB undo logs. The encrypted undo tablespaces are handled the same way as the encrypted tablespaces for InnoDB tables. See Chapter 6, Working with Encrypted InnoDB Tablespaces for details.

mysqlbackup now supports encrypted InnoDB redo logs. The encrypted redo tablespaces are handled the same way as the encrypted tablespaces for InnoDB tables. See Chapter 6, Working with Encrypted InnoDB Tablespaces for details.

To avoid mysqlbackup failing to catch up with the growing redo log during a backup operation and missing redo log data, mysqlbackup now utilizes redo log archiving, a new feature available on MySQL Server 8.0.17. Redo log archiving can be skipped using the new mysqlbackup option --no-redo-log-archive. See Chapter 7, Backing up Using Redo Log Archiving for details.

The --incremental-base option now accepts a new value, history:last_full_backup, which makes it easy to create a differential backup. See the description of --incremental-base for details.

mysqlbackup now supports a faster way to create incremental backups by using the page tracking functionality on MySQL Servers. To use this new feature, set --incremental=page-track. See Incremental Backup Using Page Tracking for details.

The --uncompress option is now supported for the extract operation, so that files from a compressed single-file backup can now be extracted and uncompressed with a single command.

Two new options, --compression-algorithms and --zstd-compression-level, have been introduced for configuring compression for server connections. See Section 20.2, “Connection Options” and Command Options for Connection Compression for details.

The image-to-backup-dir command is now an alias for the extract command.

It is now safe to have DDL operations (CREATE TABLE, RENAME TABLE, DROP TABLE, ALTER TABLE, and operations that map to ALTER TABLE like CREATE INDEX) happening on the server in parallel with a backup operation; see details described here for some limitations. Due to this new feature, the user by which mysqlbackup connects to the MySQL server must now be granted the SELECT ON *.* privilege; see Section 4.1.2, “Grant MySQL Privileges to Backup Administrator”.

Master key rotation for binary log encryption on the server in between a full and an incremental backup, as well as between two incremental backups performed by mysqlbackup, is now supported. During an incremental backup, mysqlbackup now records encryption information for all the encrypted binary log files (including those already backed up in earlier full or incremental backups) unless the --skip-binlog option is used, in which case a warning is given that the older binary log files might become unrestorable.

Also, the --skip-binlog option now makes binary log to be skipped not just for the current backup operation, but also for all subsequent incremental backups that are based on the current backup.

The logging for backup restore has been improved: at the steps for setting the sizes of the log files, the names of the log files are now included.

mysqlbackup now prints a stack trace after being terminated by a signal.

When mysqlbackup fails to connect to a server, the warning returned by mysqlbackup now includes the hostname and port number for TCP connections, and the socket information for socket connections. This is particularly helpful for a Group Replication setup, for which mysqlbackup might attempt to connect to more than one host.

The storage engine for the mysql.backup_progress table on a backed-up server has switched from CSV to InnoDB, and a composite index is now created on the table's backup_id, current_timestamp columns. Also, when working with a Group Replication setup, mysqlbackup now makes the backup_progress table available to all members of the server group by making sure that the table is updated on a primary node during each mysqlbackup operation.

When MySQL Enterprise Backup 8.0.19 or later tries to perform its first full backup on a database, it automatically checks the format of the mysql.backup_progress table. If it detects that the table is in the old format (which means the server has been upgraded from 8.0.18 or earlier and has been backed up by MySQL Enterprise Backup before), it attempts to perform an update on the table automatically. New privileges for the mysqlbackup user on the server are required for the table upgrade; see Appendix F, Backup Progress Table Update for details.

mysqlbackup now includes the configuration files auto.cnf and mysqld-auto.cnf from a server in its backup (except for a TTS backup). They are restored to the target server's data directory as backup-auto.cnf and backup-mysqld-auto.cnf respectively. To use those files to configure your restored server, rename them to their original names before starting the server.

For the backup-to-image, extract, list-image, and copy-back-and-apply-log commands, any relative path specified with --backup-image is now taken to be relative to the current directory in which the command is run.

The tablespace_tracker file has been simplified: it now contains only two fields for each external tablespace: server_file_path and space_id. mysqlbackup no longer relies on the file for information on the backup_file_path and the tablespace type, which means that users no longer need to update the tablespace_tracker file when they move a directory backup to a new location.

Table-Level Recovery (TLR) now allows selective restores of tables or schemas from full backups; see Section 5.1.4, “Table-Level Recovery (TLR)” for details.

The legacy option --include is now deprecated. A deprecation warning is now issued by mysqlbackup whenever the option is used. The --include-tables and --exclude-tables options should be used instead for partial backups and restores.

For a backup-to-image operation, when a relative path is specified for the --backup-image option, mysqlbackup interprets the file path given as relative to the backup directory.

Encrypted InnoDB tables can now be included in partial backups and restores using transportable tablespaces (TTS).

Encrypted InnoDB tables are now being verified in validate operations.

Compressed InnoDB files are now being verified in validate, backup, and backup-to-image operations.

The storage engine for the mysql.backup_sbt_history table on a backed-up server has switched from CSV to InnoDB. Also, an auto-increment primary key id column has been added to the table. When working with a Group Replication setup, mysqlbackup now makes the backup_sbt_history table available to all members of the server group by making sure that the table is updated on a primary node during each mysqlbackup operation.

When MySQL Enterprise Backup 8.0.21 or later tries to perform its first full backup on a database using the SBT API, it automatically checks the format of the mysql.backup_sbt_history table. If it detects that the table is in the old format (which means the server has been upgraded from 8.0.20 or earlier and has been backed up by MySQL Enterprise Backup before using the SBT API), it attempts to perform an update on the table automatically. New privileges for the mysqlbackup user on the server are required for the table upgrade; see Appendix E, SBT Backup History Table Update for details.

Commands for operations on compressed backups (copy-back, copy-back-and-apply-log, apply-log, etc.) have been simplified: the --uncompress option is no longer needed, except for extract and image-to-backup-dir operations that do not use the --src-entry option.

Commands for operations on incremental backups (copy-back, copy-back-and-apply-log, apply-log) have been simplified: the --incremental option is no longer needed for those operations.

A backup now fails when a binary or relay log file is purged while the backup is going on; it also fails when mysqlbackup finds a binary log file missing on the server (however, if a relay log file is missing, the backup continues).

The tool_name column of the backup_progress table on the MySQL server is now populated with the full mysqlbackup command that invoked a backup operation.

The file backup_gtid_executed.sql was not included in a TTS backup for a replica server using GTIDs. The file is now included in a TTS backup as long as the --slave-info option is used.

MySQL Enterprise Backup now supports cloud backup and restore using the Object Storage service of Oracle Cloud Infrastructure (OCI) with Pre-Authorized Request (PAR) URLs. A new option, --cloud-par-url, has been introduced for the purpose. See Section 4.3.1.3, “Backing Up to Cloud Storage” for details.

Also, OAuth is no longer supported by MySQL Enterprise Backup for authentication with the OCI Object Storage service.

MySQL Enterprise Backup now supports S3-compatible cloud storage services with a new option --cloud-host option, by which users can specify the hostname of the storage service.

MySQL Enterprise Backup now supports user authentication by the server using LDAP. Two new options, --plugin-dir and --enable-cleartext-plugin, have been introduced to support this feature. See Chapter 16, Using LDAP for Server Authentication for details.

MySQL Enterprise Backup has extended the types of cloud storage services it supports; see Section 20.15, “Cloud Storage Options” for details.

Logging on cloud operations with OCI object storage now provides more information.

A new option, --cloud-chunk-size, has been introduced for specifying the size of a chunk when chunked transfer is enabled for cloud operations. See the description for --cloud-chunk-size for details.

For a cloud backup operation to an Amazon S3-compatible storage service, a check on whether the bucket exists on the storage service has been added to the beginning of the operation. If the specified bucket does not exist, mysqlbackup throws an error and quits the operation.

The --rename option now works with both full and partial restores:

The --free-os-buffers option can now take an argument, which tells mysqlbackup how to utilize posix_fadvise() (on supported platforms) for reducing the impact of mysqlbackup on the system performance. See the option description of --free-os-buffers for details.

mysqlbackup now supports the keyring components on MySQL Servers: InnoDB tables encrypted by utilizing the component_keyring_file and component_keyring_encrypted_file can now be backed up and restored by mysqlbackup. See Chapter 6, Working with Encrypted InnoDB Tablespaces for details.

The --verbose option is now synonymous with --trace=1.

The --debug option now accepts more arguments for providing various kinds of debugging information. See the option description for --debug for details.

It is now possible to create an incremental backup with page tracking with a DDL operation taking place in parallel with the backup. Some limitations apply; see more details here.

The TLSv1 and TLSv1.1 connection protocols were deprecated in MySQL 8.0.26 and are now removed in MySQL 8.0.28. The removed protocols are considered invalid for use with the --tls-version option for connecting mysqlbackup to the server. Instead, connections can be made using the more-secure TLSv1.2 and TLSv1.3 protocols.

Old page tracking files on the server created by the mysqlbackup component can now be purged by a new loadable function, mysqlbackup_page_track_purge_up_to(). See Incremental Backup Using Page Tracking for details. Thanks to Rahul Malik for contributing to this feature.

The --force option has been deprecated: it is now ignored by mysqlbackup, and a warning appears whenever it is used with a mysqlbackup command.

The log-bin and relay_log options can now be specified in the [mysqld] section of the server configuration file supplied with the --defaults-file option during a restore operation. However, the values specified that way take lower precedence than the values specified for the options in the [mysqlbackup] section, and values given at the command line override any values given in the configuration file. See Chapter 21, Configuration Files and Parameters for more information on the use of configuration files.

The way the redo log is maintained on the MySQL Server has been changed since release 8.0.30. To create an incremental backup using only the redo log, you should register mysqlbackup with the server as an external consumer of the redo log by using the innodb_redo_log_consumer_register() UDF and, after each redo-log-only incremental backup, run the innodb_redo_log_consumer_advance($lsn) UDF to advance to a new LSN checkpoint. See Creating Incremental Backups Using Only the Redo Log for details.

The options --slave-info and --safe-slave-backup-timeout have been deprecated. The following aliases should be used instead:

The new options work in the same way as the old ones, only the terminology used for each statement has changed. Deprecation warnings are issued if the old options are used.