MySQL Enterprise Backup 8.0 Release Notes
MySQL Enterprise Backup 8.0.17 is the latest release for MySQL Enterprise Backup. It only supports MySQL Server 8.0.17. For earlier versions of MySQL 8.0, use the MySQL Enterprise Backup version with the same version number as the server. For MySQL server 5.7, please use MySQL Enterprise Backup 4.1, and for MySQL Server 5.6 and 5.5, please use MySQL Enterprise Backup 3.12.
Before the current release, when backing up a server that used the keyring_okv plugin for InnoDB table encryption, mysqlbackup must not be run by a sudo user of its operating system. This restriction has now been removed. (Bug #29020232)
The --datadir
option is no longer
required for restoring a TTS
backup. If the option is specified and its value does not
match with that of the target server, the restore will be
aborted.
(Bug #28546760)
The --incremental-base
option now
accepts a new value,
history:last_full_backup
, which makes it easy
to create a
differential
backup. See the description of
--incremental-base
for details.
(WL #12884)
To avoid mysqlbackup failing to catch up with
the growing redo log during a backup operation and missing redo
log data, mysqlbackup now utilizes
redo log
archiving, a new feature available on MySQL Server
8.0.17. Redo log archiving can be disabled using the new
mysqlbackup
option
--no-redo-log-archive
. See
Backing up Using Redo Log Archiving for details.
(WL #12257)
mysqlbackup now supports encrypted InnoDB redo logs. The encrypted redo tablespaces are handled the same way as the encrypted tablespaces for InnoDB tables. See Working with Encrypted InnoDB Tablespaces for details. (WL #10137)
A backup failed when the value of the server's system variable
innodb_undo_directory
contained
in itself the file path for the server's data directory. It was
due to a mishandling of the file path prefix of the undo
tablespace directory by mysqlbackup, which
has been corrected by this fix.
(Bug #29849566)
Restore of an incremental backup failed if its base full backup
had been restored with the
--skip-binlog
option.
(Bug #29757701)
When the binary log on the server was more than one level below the data directory on the directory tree, mysqlbackup failed to copy the binary log into a backup. This was due to an error on parsing the path of the binary log directory, which has been corrected by this fix. (Bug #29710251)
If a relative path was used with the
backup_innodb_data_home_dir
option
when backing up a server, the whole directory specified by the
option was being copied into the target server's data directory
during a restore of the backup. Not only was that not the
expected behavior of mysqlbackup, but it also
made subsequent backups of the server failed when the same
argument for
backup_innodb_data_home_dir
was used
again.
(Bug #29613025)
During a backup operation, when a table or database name contains a slash (/), mysqlbackup always treated the corresponding tablespace as an external tablespace; if that was not actually the case, restore for the backup was going to fail. With this fix, mysqlbackup checks if the tablespace is really external and then handles it appropriately. (Bug #29472939)
External undo tablespaces were missing after a restore of a
backup directory extracted from a backup image using the
image-to-backup-dir
command. It was
because of the mishandling of the
tracker file for
external tablespaces by the
image-to-backup-dir
command, which
has been corrected by this fix.
(Bug #29401027)
While no upgrade path exists between MySQL Enterprise Backup 4.1 and 8.0, an attempt to update the mysqlbackup package from release 4.1.3 to 8.0.16 on Ubuntu failed with the complaint that the update tried to overwrite the installation directory for mysqlbackup. With this fix, package conflict information has been added so that at the same attempt, the old package is uninstalled (with the user's consent) before the new package is installed. (Bug #29314267)
When using MySQL Enterprise Backup 8.0 to back up MySQL Server 5.7, an error was thrown, and the error message suggested a wrong version of MySQL Enterprise Backup to be used for the Server. With this fix, the appropriate version of MySQL Enterprise Backup is suggested. (Bug #29195233)
When backing up a server that used the
keyring_okv plugin for
InnoDB table encryption, if the
--host
,
--user
, and
--port
options were not specified
with the mysqlbackup command via the command line or a
configuration file, the backup failed. It was because in that
case, mysqlbackup had no values for those
options it could use to connect to the server that took care of
keyring operations. With this fix, default values are now set,
so that mysqlbackup connects to the server on
localhost
as root
and on
port 3306
for keyring operations when those
options are not specified.
(Bug #29015923)
A copy-back-and-apply-log
operation
for a compressed backup created using the
--backup_innodb_data_home_dir option
with a relative file path terminated with signal 6.
(Bug #28967141)
mysqlbackup hung during a restore operation when the backup contained more than a hundred InnoDB tablespaces. (Bug #28884254, Bug #29674585)
A restore operation for a compressed backup failed with an
unexpected end of file
error when the backup
was created using
--compress-method=zlib
and the
innodb_page_size
was smaller
than 16KB.
(Bug #28623215)
A backup created on an EL7 platform containing InnoDB tables encrypted with MySQL Enterprise Transparent Data Encryption (TDE) could not be restored to a server on a Solaris platform. It was because in this case, the source and the target platforms of the backup used different byte ordering formats, causing difficulties in loading the encryption key from the backup. This fix prevents the issue by adding detection and conversion utilities for different system architectures. (Bug #28569367)
Using the --uncompress
option for
restoring a backup not created with the
--compress
option caused the
operation to fail with the error No such file or
directory
. With this fix, the proper error is thrown
in the situation.
(Bug #28334690)
A backup failed with the error Log scan was only able
to reach...
when there was a large amount of DML
activities occurring in parallel on the server that was being
backed up.
(Bug #27555969)
During the InnoDB buffer pool dump in a backup operation, mysqlbackup sometimes reported failure for the dump while it was actually still in progress. The fix prevents the problem by improving the way mysqlbackup checks for the status of the dump. (Bug #27185901)