MySQL Enterprise Backup now supports optimistic incremental backup, in which mysqlbackup scans only those InnoDB data files that have been modified since the last backup for changed pages and then saves them into the incremental backup. It potentially makes incremental backups faster. See Full-scan versus Optimistic Incremental Backup for details.

A full set of exit codes have now been implemented for MySQL Enterprise Backup. Also, a new mysqlbackup command, print-message, returns an exit message for any given exit code supplied with the new option --error-code. See Section 13.1, “Exit codes of MySQL Enterprise Backup” for details.

Apply-log operations can now be performed with multiple worker threads in parallel, which can improve performance for the operations. The number of threads to be used can be specified with the --process-threads option.

MySQL Enterprise Backup now supports the --ssl-mode option, which enables you to specify the security state of the connection to the server. It replaces the client side --ssl and --ssl-verify-server-cert options, which are now deprecated. See the description of the --ssl-mode option in MySQL 5.7 Reference Manual for details.

A number of measures have been implemented to increase the performance for hot backups by decreasing the duration of the final phase of hot backups in which the server is locked. See the MySQL Enterprise Backup 4.1 Release Notes for details.

A new option, --skip-final-rescan, makes mysqlbackup skip the final rescan for InnoDB tables that are modified by DDL operations after the database has been locked near the end of a backup operation. See the description for --skip-final-rescan for details.

The output by mysqlbackup, which goes to the stderr stream and the message log, has now been improved to include the timestamps and thread IDs for all steps taken by mysqlbackup, in order to provide more information for debugging purposes.

The backup_history table now includes the following new columns:

For MySQL Enterprise Backup 4.1.1 and later working with MySQL Server 5.7.21 and later: Servers' use of the keyring_encrypted_file and keyring_aws plugins is now supported by MySQL Enterprise Backup. See Chapter 6, Working with Encrypted InnoDB Tables for details.

For MySQL Enterprise Backup 4.1.1 and later: HTTP Basic Authentication and non-chunked transfer are now supported for backup and restore using OpenStack Swift-compatible object storage services. See Section 16.15, “Cloud Storage Options” for details.

For MySQL Enterprise Backup 4.1.2 and later: OAuth is now supported for Oracle Cloud Infrastructure Object Storage client authentication. Two new options, --cloud-storage-url and --cloud-oauth-token, have been introduced for the purpose. See Section 16.15, “Cloud Storage Options” for details.

For MySQL Enterprise Backup 4.1.2 and later: The binary log for a backed-up server, instead of being restored always to the data directory on the target server, is now restored by default to the same location it was found on the backed-up server. It can also be restored to a different location specified with the new --log-bin option.

For MySQL Enterprise Backup 4.1.2 and later: The relay log for a backed-up slave server, instead of being restored always to the data directory on the target slave server, is now restored by default to the same location it was found on the backed-up slave server. It can also be restored to a different location specified with the new --relay-log option.

For MySQL Enterprise Backup 4.1.2 and later: 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 8, 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.

For MySQL Enterprise Backup 4.1.2 and later: 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 required by mysqlbackup for the mandatory table migration to take place.

For MySQL Enterprise Backup 4.1.3 and later: 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).