The --skip-binlog and --skip-relaylog options can now be used to skip the copying back of the binary log and relay log onto the server during a restore. This is particularly useful for users who do not want those logs appearing in the restored server's data directory, as that is always the location to which mysqlbackup will restore them, regardless of their original locations on the backed-up server. (Bug #19887998)

MySQL Enterprise Backup no longer writes to the incremental_base_lsn column in the mysql.backup_history table when creating an incremental backup, as the column is no longer used by mysqlbackup. Note that the column will eventually be dropped from the table in future releases of MySQL Enterprise Backup. (Bug #19548604)

The --force option can now be used during the restore of a full backup to overwrite existing data in a nonempty target directory. See the description for the --force option for details. (Bug #19266491)

The binary log file and relay log files (in the case of a slave server) are now compressed when they are being included in a compressed backup and decompressed during a restore. (Bug #19149210)

The start and end LSNs reported after an incremental backup was finished could be confusing to the users if there had been no changes to the database since the last full backup. With this fix, mysqlbackup simply reports that “No new log record found” in the situation. (Bug #18399069)

MySQL Enterprise Backup now supports table renaming when a single table is restored from a backup created using transportable tablespace (TTS). See the description for the --rename option for details.

MySQL Enterprise Backup now supports cloud backup and restore using OpenStack Object Storage (“Swift”) 1.0. Authentication can be handled either through Swift's own TempAuth authentication system or the OpenStack Identity Service (Keystone) 2.0. A number of new command options have been introduced to support OpenStack Object Storage; see Cloud Storage Options, for details.

Microsoft Windows: On Windows platforms, when symbolic links were involved in the file path arguments for options like --backup-dir or --backup-image, mysqlbackup failed with an error. With this fix, mysqlbackup works in the situation as long as the arguments do not involve dangling symbolic links, in which case mysqlbackup throws an error instead of creating any directory or file under any symbolically-linked locations. (Bug #19608231)

When a base backup did not include the binary log or relay log files, updating the base backup up with a subsequent incremental backup using the apply-incremental-backup command would fail, unless the incremental backup was created with the --skip-binlog and --skip-relaylog options. With this fix, the copying of the binary log and relay log is automatically skipped during an incremental backup when its base backup does not include those logs. (Bug #20594802)

Performing a backup-and-apply-log and then a copy-back-and-apply-log caused the redo log files to be skipped during the restore process and thus missing on the restored server. This was because in this non-typical sequence of operations, the apply-log step (by which the redo log is usually copied) in the copy-back-and-apply-log step was skipped, as an apply-log operation had already been performed by the backup-and-apply-log step. This fix makes sure the copying of the redo log files is not skipped in that situation. (Bug #20583014)

Near the end of the second phase of an optimistic backup, mysqlbackup rescanned the tables that had already been copied in the first, optimistic phase of the backup, and tried to copy again any of those tables that had been modified since they were first copied; this attempt to overwrite the already-copied table by a recopying caused a file creation error. With this fix, any such table changes are rightfully ignored, as the changes have been recorded in the redo log already and will be taken care of later by the apply-log operation. (Bug #20583014)

If an incremental image backup contained a large number of pages from a single table, the restore of the incremental backup using the copy-back-and-apply-log command might fail. (Bug #20492274)

Extracting individual files from an image backup using the extract command and the --src-entry option resulted in segmentation faults, if the binary log files had been included into the backup. (Bug #20458681)

A copy-back-and-apply-log operation failed for an image backup if the --backup-innodb_* options (for example, --backup_innodb_data_home_dir, --backup_innodb_log_group_home_dir, and --backup_innodb_undo_directory) were used during the operation. With this fix, these options are ignored by mysqlbackup during the operation. (Bug #20451354)

After a RESET SLAVE statement was executed on a slave server, a subsequent backup for the slave server failed with an error, as mysqlbackup could not copy the relay log file from the server. This was because mysqlbackup could not detect the location of the current relay log after the slave reset, and the this fix makes sure mysqlbackup knows how to do that. (Bug #20180440, Bug #75074)

During the restore of an offline image backup, the master.info and relay-log.info files were sometimes not copied into the data directory on the target server. (Bug #19973192)

References: This issue is a regression of: Bug #19883801.

Offline backups failed unless the --skip-binlog option was used, because the default action of copying the binary log failed. With this fix, the binary log can now be successfully included in an offline backup. (Bug #19941735)

References: This issue is a regression of: Bug #19883801.

When creating a full 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 backup based on the full backup, the attempt to copy the binary log files from the server into the incremental backup (which has been the default behavior of MySQL Enterprise Backup since 3.11.0) 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 backup no longer fails." (Bug #19915713)

If a binary log file on the server got removed as a backup was taking place, the backup failed, as mysqlbackup could not find the binary log file it wanted to copy into the backup. With the fix, mysqlbackup continues to finish the backup operation even if some binary log files have been deleted, except for the case of an incremental backup (for which the backup is still going to fail).

Also, with this fix, only the binary log files listed in the binary log index file are copied back to a server during a restore, so that purged binary log files, even backed up, are not restored. (Bug #19849326)

When mysqlbackup encountered a corrupted .frm file during a backup, it threw an error, tried to continue with the backup, and then hung eventually. With this fix, mysqlbackup just gives a warning message (“WARNING: An error occurred while adding manifest information for backup”), and then continues with the backup as usual. (Bug #19608231)

When trying to restore a non-TTS backup to a running server, mysqlbackup overwrote the data on the server without giving any warning. This fix makes mysqlbackup terminate the restore of a non-TTS full backup with an error whenever it finds the target data directory to be nonempty, and then issue a message that the --force option should be used if the user wants the original data to be overwritten.

(Bug #19266491)

The binary log and relay log index files included in a backup pointed to the files' original locations on the backed-up server. That might prevent the restored server to be started properly. With this fix, the log files' paths in the index files are properly updated during a backup to point to the files' locations in the backup directory. (Bug #19255992)

Compression information displayed after the second phase of a compressed, optimistic backup was only for the second phase of the backup. With this fix, the information now reflects the total compression performed for the whole process, including both the first and second phases. (Bug #19200562)

The list-image operation on cloud backups failed. This was because the operation requires transfer of data without buffering, but mysqlbackup was transferring data in buffered mode by default. This fix makes mysqlbackup download data for the operation without buffering—which is possible as long as the cloud proxy supports HTTP range hearers. (Bug #19162974)

When restoring an incremental backup using the copy-back-and-apply-log subcommand on Windows platforms, the operation failed when long file paths were used in the command-line options. (Bug #18448617)