MySQL Enterprise Backup 3.12 Release Notes  /  Changes in MySQL Enterprise Backup 3.12.3 (2016-05-09)

Changes in MySQL Enterprise Backup 3.12.3 (2016-05-09)

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)

  • 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) replica 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)

Bugs Fixed

  • 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)

  • 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)

  • 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)