MySQL Enterprise Backup v3.8.2, a maintenance release of online
MySQL backup tool, is now available for download from My Oracle Support
(MOS) website as our latest GA release. It will also be available via the Oracle Software Delivery Cloud in approximately 1-2 weeks.
A brief summary of the changes in MySQL Enterprise Backup version 3.8.2 is given below.
A. 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. For more details, refer this page
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). For more details on progress report options, refer here
B. Bugs Fixed:
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)
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)
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.
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)
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)
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)
Please post your questions / comments about Backup in forums.
Thanks,
MEB Team
