Functionality Added or Changed

Offline backups are no longer supported by
mysqlbackup. As a result, a number of options
used for offline backup operations have been removed. See
What's New in MySQL Enterprise Backup 8.0? for details.
(Bug #27429244)

The server option --secure-auth, deprecated
since MySQL 5.7.5, is no longer supported by
mysqlbackup.
(Bug #27265328)

Information on the executed GTIDs is now included in the
mysqlbackup output and the backup log when
the backed-up server has GTIDs enabled.
(Bug #25978803)

The binary log for a backed-up server, instead of being restored
always to the data directory on the target server, is now
restored by default to the same location it was found on the
backed-up server. It can also be restored to a different
location specified with the new
--log-bin option.
(Bug #25141738, Bug #83927)

The relay log for a backed-up slave server, instead of being
restored always to the data directory on the target slave
server, is now restored by default to the same location it was
found on the backed-up slave server. It can also be restored to
a different location specified with the new
--relay-log option.
(Bug #25141738, Bug #83927)

The backup_history table now includes a
server_uuid column, which stores the value of
the server_uuid of
the backed up server.

The options --ssl and
--ssl-verify-server-cert, already deprecated in
MySQL Enterprise Backup 4.1, have now been removed. Use the
--ssl-mode option instead to
configure the security mode of your connection to the server.

mysqlbackup could not restore the auto
increment values in tables and the corruptions flags for indexes
onto a server. The tasks are now made possible by having
mysqlbackup copying onto the target server
blocks of redo logs that cover the duration from the latest
checkpoint up to the backup end time, so that the restored
server can, during the recovery phase at its first start,
restore the auto increment values and the corruption flags using
those blocks.

Bugs Fixed

After restoring a full backup, if the following restore of an
incremental backup changed the restore location of the undo log,
either mysqlbackup hung, or the restored
server failed to start. With this fix,
mysqlbackup quits with a proper error
(“Undo tablespace in the base backup not found”) in
the situation.

Users should make sure the undo log location does not change
between successive restores of a full and an incremental
backups, or of two incremental backups.
(Bug #27530916)

When restoring an incremental backup containing encrypted InnoDB
tables to a MySQL Community Server, the password provided to
mysqlbackup with the
--encrypt-password option was never
validated, so that when the wrong password was given, the
restore still succeeded, but the restored server could not be
started. With this fix, mysqlbackup throws an
error and stops the restore if the password is wrong.
(Bug #27483449)