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)

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)