Documentation Home
MySQL Enterprise Backup 3.8 User's Guide
Download this Manual
PDF (US Ltr) - 0.9Mb
PDF (A4) - 0.9Mb

MySQL Enterprise Backup 3.8 User's Guide  /  ...  /  Changes in MySQL Enterprise Backup 3.8.2 (2013-06-18)

D.1 Changes in MySQL Enterprise Backup 3.8.2 (2013-06-18)

Functionality Added or Changed

  • MySQL Enterprise Backup has a new --on-disk-full command line option. mysqlbackup could hang when the disk became full, rather than detecting the low space condition. mysqlbackup now monitors disk space when running backup commands, and users can now specify the action to take at a disk-full condition with the --on-disk-full option. See Section 4.1.11, “Performance / Scalability / Capacity Options” for details. (Bug #13817288, Bug #13804407)

  • MySQL Enterprise Backup has a new progress report feature, which periodically outputs short progress indicators on its operations to user-selected destinations (for example, stdout, stderr, a file, or other choices). This feature is controlled by the new progress report options described in Section 4.1.12, “Progress Report Options”.

Bugs Fixed

  • MySQL Server failed to start after a backup was restored if there had been online DDL transactions on partitioned tables during the time of backup. (Bug #16924499)

  • When --innodb-file-per-table=ON, if a table was renamed and backup-to-image was in progress, apply-log would fail when being run on the backup. (Bug #16903973)

  • apply-log failed if ALTER TABLE ... REORGANIZE PARTITION was applied to partitioned InnoDB tables during backup. (Bug #16721824, Bug #16903951)

  • apply-incremental-backup might fail with an assertion error if the InnoDB tables being backed up were created in Barracuda format and with their KEY_BLOCK_SIZE values different from the innodb_page_size. This fix ensures that different KEY_BLOCK_SIZE values are handled properly during incremental backup and apply-incremental-backup operations.


    Perform incremental backups with MySQL Enterprise Backup 3.8.2 instead of any older version to ensure a successful apply-incremental-backup.

    (Bug #16423621, Bug #16842291)

  • If a table was renamed following a full backup, a subsequent incremental backup could copy the .frm file with the new name, but not the associated .ibd file with the new name. After a restore, the InnoDB data dictionary could be in an inconsistent state. This issue primarily occurred if the table was not changed between the full backup and the subsequent incremental backup. (Bug #16262690)

  • After a full backup, if a table was renamed and modified, apply-incremental-backup would crash when run on the backup directory. (Bug #16262609)

  • The value of the binary log position in backup_variables.txt could be different from the output displayed during the backup-and-apply-log operation. (This issue did not occur if the backup and apply-log steps were done separately.) (Bug #16195529)

  • A backup process might hang when it ran into an LSN mismatch between a data file and the redo log. This fix makes sure the process does not hang and it displays an error message showing the name of the problematic data file. (Bug #14791645)

  • When using the --only-innodb-with-frm option, MySQL Enterprise Backup tried to create temporary files at unintended locations in the file system, which might cause a failure when, for example, the user had no write privilege for those locations. This fix makes sure the paths for the temporary files are correct. (Bug #14787324)

User Comments
Sign Up Login You must be logged in to post a comment.