MySQL Enterprise Backup 4.0 Release Notes  /  Changes in MySQL Enterprise Backup 4.0.1 (2016-05-26)

Changes in MySQL Enterprise Backup 4.0.1 (2016-05-26)

Functionality Added or Changed

  • There are two enhancements on how you can configure SSL host authenticate for cloud operations of MySQL Enterprise Backup:

    • A CA certificate directory, in addition to the default folder of the system, can now be specified with the new --cloud-ca-path option.

    • mysqlbackup now supports authentication using a CA bundle file, whose path is specified by the new --cloud-ca-info option.

    See descriptions for the two new options in Cloud Storage Options for more information. (Bug #22761313)

  • mysqlbackup used to sync all data from the buffer cache to the hard disk before closing all tables at the end of a backup operation. However, for systems with slow storage devices and databases with a huge number of tables, the sync would increase the backup time significantly. To shorten the backup time for those and other cases, starting with this release, the sync is no longer performed automatically. Users who want the sync to be performed at the end of a backup have to use the new --free-os-buffers option. (Bug #22561345)

  • MySQL Enterprise Backup now supports backup of slave servers in a multi-source replication setup. (Bug #21830316, Bug #22283631)

  • To avoid completing a backup of a slave server when temporary tables are still open on the slave, which will cause the restored slave server to be in an inconsistent replication state, mysqlbackup now has a new mechanism for ensuring that all temporary tables have already been closed before finishing a slave backup. See Temporary tables on statement-based replication (SBR) slave for details. A new option, --safe-slave-backup-timeout, has been created for specifying the time mysqlbackup will wait for all temporary tables to be closed before it times out. (Bug #19158516)

  • The compression options can now be used with the backup-and-apply-log operation to create a directory backup that is prepared and compressed; the backup can then be restored using the copy-back operation and the --uncompress option. (Bug #18913565)

  • During a copy-back-and-apply-log or a copy-back operation, mysqlbackup now checks that the specified values for the innodb_log_files_in_group and innodb_log_file_size options match those recorded in the backup's backup-my.cnf file, and throws an error if the values do not match. This prevents mysqlbackup from restoring the backup with the wrong parameters, which would result in a restored server that cannot be started. (Bug #14751027)

  • Values for MASTER_USER and MASTER_PORT are now included in the CHANGE MASTER TO statement in the slave information file (meta/ibbackup_slave_info) when the --slave-info option is used for backing up a slave server. (Bug #14213115)

Bugs Fixed

  • Microsoft Windows: On Windows platforms, mysqlbackup crashed instead of quitting gracefully when the --datadir option was not specified for a copy-back or copy-back-and-apply-log operation. (Bug #22069093)

  • An apply-log operation failed when a RENAME TABLE statement within the redo log was applied to the backup even when the renamed table was already included into the backup. This fix prevents the problem by making mysqlbackup ignore dirty (intermediate) log records when (a) the new table name is already in used, or (b) if the tablespace has not been loaded into memory with the old table name. (Bug #23068440)

  • An incremental or compressed backup might fail with an end-of-file error if there are large data files that kept growing during the backup. It was because, as the data files expanded, the write process altered the file sizes, which confused the read process for the same files. With this fix, file sizes and information on them is now properly handled. (Bug #23048004)

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

  • Restoring a cloud backup sometimes failed with Error 18: Transferred a partial file. It was because mysqlbackup created wrong range headers for its REST requests for partial downloads. (Bug #23035334)

  • mysqlbackup crashed when a validate operation was performed on an incremental backup that contained an undo tablespace but not a system tablespace. It was because mysqlbackup did not handle data files for undo tablespaces properly, and this fix corrects that. (Bug #22960185)

  • Attempts to restore a compressed image backup using the copy-back-and-apply-log command failed with ERROR: InnoDB: Missing MLOG_FILE_NAME or MLOG_FILE_DELETE for redo log record .... It was because the undo tablespaces were not loaded, so that the log operations on them failed. This fix ensures that the undo tablespaces are loaded. (Bug #22914556)

  • If a table had been renamed during a backup operation, it sometimes got copied twice into the backup, once under its old table name and another time under its new name. It was because mysqlbackup, when checking for tables that have been changed during the backup process, only checked tables by their .ibd file names. With this fix, the tablespace ID is also checked, so that a renamed table will be recognized as such and will not be copied twice. (Bug #22859445)

  • Sometimes, when sizes of the data files kept growing during a single-file backup, a broken image backup might be produced, causing subsequent commands on it (for example, validate or copy-back-and apply-log) to fail. It was due to a mismatch of the file size given in the image file's header and the actual file size on disk, which is now prevented by this fix. (Bug #22613568)

  • Offline backups sometimes failed, with occasional crashes of mysqlbackup. (Bug #22595461)

  • For a backup of a slave server, the file name of the master server's binary log and the binary log position for starting replication, which were stored in the file backup_varaibles.txt in the backup as masterlog_file and masterlog_pos, got corrupted when an apply-log or copy-back-and-apply-log operation was applied to the backup. (Bug #22329306)

  • When mysqlbackup came across a file of an unknown file type and its path name contained characters that mysqlbackup could not convert to the file system character set, it threw an error. With this fix, mysqlbackup continues with its operation in the situation after giving a warning. (Bug #22098742)

  • A backup failed if, towards the end of the backup process, mysqlbackup found the binary log file that was current at the beginning of the backup had been purged. With this fix, mysqlbackup now ignores the fact that the file has been purged, resets the log position to the now current binary log file, and continues with the backup without raising any issues. (Bug #21655145)

  • During a backup, mysqlbackup performed, by default, an SQL query to get storage engine information that was to be put into the backup_history table. Because the query caused all table files on the server to be scanned, it consumed a great amount of IO resources when there were many tables on the server, resulting sometimes in serious performance issues. With this fix, only tables included in the backup are scanned, thus reducing the IO stress on the server. (Bug #21098174)

  • When creating a compressed backup, mysqlbackup threw an error if a table on the server was dropped in the middle of the process. With this fix, the dropped table is ignored (as it does not need to be restored) and mysqlbackup finishes without throwing an error. (Bug #21087079)

    References: See also: Bug #18358912.

  • validate operations for backup images and backup-to-image operations left over a temporary folder (/tmp) after the operations were over. (Bug #20912357)

  • Backups failed for a server that had once been started with the --log-bin option and then restarted without it. It was because mysqlbackup, seeing the old binary log index file on the server, looked in vain for the current binary log files, reported that they could not be found, and then exited. With this fix, mysqlbackup checks if binary logging is enabled for the server; if it is not, mysqlbackup then skips the copying of the binary log into the backup. (Bug #20873010)

  • A backup of a slave server failed if, during the backup, a relay log file got purged from the slave server (for example, due to a log file rotation). With this fix, backup continues even if mysqlbackup finds a relay log file missing. (Bug #20769891, Bug #76312, Bug #21655314, Bug #19255925)

  • When the trace level of mysqlbackup messages was greater than 0, if the operation command for mysqlbackup was invalid or missing, a stack trace and some error messages were printed, which made it look like mysqlbackup had crashed. With this fix, a new message is now shown before the stack trace, to better explain the situation. (Bug #20281022)

  • If an incremental backup had already been applied to a directory backup with the apply-incremental-backup command and the up-to-date backup was then restored to a data directory, it was possible to restore the same incremental backup again to the data directory using the copy-back-and-apply-log command, potentially causing data inconsistencies. With this fix, the incremental data can be reapplied only when the --force option is used. Without the --force option, the copy-back-and-apply-log command skips the apply log operation if the incremental backup is a directory backup and throws an error if it is an image backup. (Bug #18004179)