The linked OpenSSL library for MySQL Enterprise Backup 4.1 has been updated to version 1.0.2k. (Bug #25615449)

A backup became corrupted if, during the backup process, a DDL operation that took advantage of MySQL server's online DDL feature occurred. This was because mysqlbackup did not support the server feature—and it still does not. This fix avoids the error by having mysqlbackup turn the server's system variable old_alter_table to “1” at the beginning of a backup if it is “0,” so that any DDL operations that take place during the backup are handled with the old table copy method. mysqlbackup then turns the variable back to “0” near the end of the backup operation.

(Bug #25217215)

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. (Bug #23508228)

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. This potentially shortens the duration for the lock and reduces the backup's impact on the server's normal operation. See the description for --skip-final-rescan for details. (Bug #21094221)

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. (Bug #20142619)

During the final stage of a backup when MySQL Enterprise Backup tried to temporarily put the database into a read-only state using the FLUSH TABLES WITH READ LOCK statement in order to copy non-InnoDB files, if a long query was running on the server at the same time, the FLUSH TABLES WITH READ LOCK statement could be taking too long to finish, holding up further queries and eventually bringing down the server.

A new mysqlbackup option --lock-wait-timeout can now be used to specify the timeout in seconds for the FLUSH TABLES WITH READ LOCK statement. If the timeout is exceeded, the statement is failed and the lock on the tables is released, so that queries held up by the lock can then be executed. mysqlbackup then retries the statement and continues with the backup. Default value for --lock-wait-timeout is 60 [seconds]. (Bug #14339483)

The backup_history table now includes the following new columns:

(WL #8416)

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 Exit codes of MySQL Enterprise Backup for details. (WL #8291)

To increase the performance for hot backups, mysqlbackup now shortens the final phase of the backups by resizing the MyISAM key cache before it locks the database with a FLUSH TABLES WITH READ LOCK statement. The resize triggers a flush of the MyISAM key cache, which reduces the time it takes to run the FLUSH TABLES WITH READ LOCK statement. The MyISAM key cache size is changed back to its original value afterward. (WL #9311)

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. (WL #9368)

The copying of redo log files into backups has been made faster, shortening the overall backup time in some cases and making it less likely that a backup fails because a redo log file has been overwritten before it is copied. (WL #9350)

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, and is performed by specifying --incremental=optimistic. See Full-scan versus Optimistic Incremental Backup for details. (WL #8416)

In order to minimize the impact of a hot backup on the MySQL server, the copying of the buffer pool dump files and some of the metadata files is now performed before the final phase of the backup in which the server instance is locked. This shortens the duration for the lock and reduces the backup's impact on the server's normal operation.

Also, to minimize the resource used on a backup, the copying of the buffer pool dump files is no longer performed for partial and offline backups, for which the buffer pool dump is usually not very useful. (WL #9309, WL #9313)

The Release number for the RPM packages of MySQL Enterprise Backup always said “1,” instead of giving the release number of the Linux distribution for which the package was built. (Bug #25538798)

An apply-log or apply-incremental-backup operation failed when, during the time the backup was created, any tables have been dropped and then recreated with the same name for more than once. (Bug #25334929)

When creating a full image backup with the --no-locking option, mysqlbackup failed to write the binary log information to the backup history table and the backup_variables.txt file. The result was that when creating an incremental image backup based on the full backup, the attempt to copy the binary log files from the server into the incremental image backup (which is the default behavior) would fail, causing the incremental backup to stop. With this fix, the binary log information is no longer missing after the full backup, so the incremental image backup no longer fails." (Bug #25296324)

References: See also: Bug #19915713.

A backup operation sometimes failed due to corruption of the copied redo log, and the corruption occurred because checksum validation for redo logs was not activated for mysqlbackup. This fix restores the checksum function, so that the validation is performed when innodb_log_checksums=ON on the backed up server. When a chuck of redo log data fails the validation, mysqlbackup tries to re-read the data from the server.

However, redo log checksum validation is not performed for offline backups, and online backups fail when the value of innodb_log_checksums is switched off on the server when the backup is in progress. (Bug #25057394)

mysqlbackup logged double entries with wrong information into the backup_history table for optimistic backups. (Bug #24502876)

Backups for a slave server in a multi-source replication setup using the --slave-info option failed. (Bug #24444950)

References: See also: Bug #21830316.

If a backed up server was configured with innodb_undo_tablespaces being nonzero, during a backup, mysqlbackup emitted meaningless warning messages about the tablespaces already existing in the cache. This fix removes those messages. (Bug #24400230)

During an apply-log or a copy-back-and-apply-log operation on a backup with encrypted InnoDB tables, if no value was specified for the --encrypt-password option used, the operation failed with the complaint that no encryption password was specified. With this fix, mysqlbackup asks the user for the encryption password when it is in the same situation. (Bug #24364442)

An apply-log operation failed for a backup of a server that contained tablespaces outside of its data directory. It was because those tablespaces, unlike tablespaces in the data directory, were not loaded by mysqlbackup before the apply-log operation started. This fix ensures all tablespaces are loaded. (Bug #22026145)

When running the backup-and-apply-log command without a connection to the MySQL server, mysqlbackup could not know the correct binary log file name and binary log position for the backup; yet, at the end of the backup-and-apply-log operation, mysqlbackup still printed out some values for the binary log file name and position, which were random in nature. (Bug #21623089)