MySQL Enterprise Backup 8.0 Release Notes
MySQL Enterprise Backup 8.0.16 is the latest release for MySQL Enterprise Backup, and supports MySQL Server 8.0.16 only. 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.
mysqlbackup now supports encrypted InnoDB undo logs. The encrypted undo tablespaces are handled the same way as the encrypted tablespaces for InnoDB tables. See Working with Encrypted InnoDB Tablespaces for details.
Near the end of the backup process, instead of locking the whole server instance for a brief period of time, mysqlbackup now applies these locks consecutively:
A backup lock on the server instance, which blocks DDLs (except those on user-created temporary tables), but not DMLs on InnoDB tables.
A
FLUSH
TABLES
operation on all non-InnoDB
tables, for copying the relevant ones among them into the
backup. This step is skipped if no user-created non-InnoDB
tables exist.
tbl_name [, tbl_name]
...
WITH READ LOCK
A brief blocking of logging activities on the server, for collecting logging-related information.
See The Backup ProcessThe Backup Process for details. The removal of the lock on the whole server instance reduces disruption to the database service by the backup operation.
The change requires that the
BACKUP_ADMIN
and
SELECT
privileges on all tables be granted to the user by which
mysqlbackup connects to the server (the
BACKUP_ADMIN
privilege is automatically granted to users with the
RELOAD
privilege when an in-place upgrade to MySQL Server 8.0 from an
earlier version is performed).
(WL #12387)
mysqlbackup now supports
dynamic changes to undo
tablespaces on the server being backed up. During a
restore, the default undo tablespaces, as well as any
non-default undo tablespaces resided in the backed-up server's
data directory, are restored to the location pointed to by the
mysqlbackup option
--innodb_undo_directory
.
Non-default, external undo tablespaces are restored to the
locations they were found on the backed-up server. See
undo log files for details.
(WL #11094)
In addition to the requirement that the target data directory
for a restore specified by the
--datadir
option must be
non-existent or empty, mysqlbackup now
enforces the same rule for the
--innodb_data_home_dir
,
--innodb_log_group_home_dir
, and
--innodb_undo_directory
options (the
--force
option cannot be used to
override the requirement on the three options).
(WL #12665, WL #12407)
Zip packages of mysqlbackup contained duplicate files, which have now been removed. (Bug #29497272, Bug #94683)
mysqlbackup might quit unexpectedly if it lost its connection to the server at the middle of a backup operation. With this fix, mysqlbackup exits gracefully in the situation after throwing the appropriate errors. (Bug #29376006)
mysqlbackup returned success for a backup to Oracle Cloud Infrastructure Object Storage Classic even after the backup failed. (Bug #29362469)
Restore of an incremental backup failed if, on the server, some binary log files had been purged in between the times the incremental backup and its base backup were made. (Bug #29306026)
A backup failed for mysqlbackup if the path
given by the --backup-dir
option was
of the Universal Naming Convention (UNC) format, as
mysqlbackup failed to create the backup
directory then.
(Bug #29190803)
A mysqlbackup operation failed when the
backup-image
option was supplied to
mysqlbackup in a configuration file instead
of on the command line.
(Bug #29157495)
A restore operation for a TTS backup failed if the backed-up
server has
ANSI_QUOTES as one of
its SQL modes, as specified in its system variable
sql-mode
.
(Bug #28979134)
mysqlbackup quit unexpectedly when the
--password
option was used twice,
with no argument given at the second time, in a
mysqlbackup command that was itself invalid
aside from the use of the --password
option.
(Bug #28894102)
When a compressed incremental folder backup was restored, the binary log files created in between the times of the base and the incremental backups were not copied onto the target server. (Bug #28773998)
A restore operation for a database containing encrypted InnoDB
tables failed without returning a proper error message when the
the --encrypt-password
option was
not used in the mysqlbackup command.
(Bug #28773077)
After restoring an incremental backup taken from a MySQL Community Server with encrypted InnoDB tables, the keyring file of the restored server became corrupted, so the server could not be started. (Bug #28422191)
A restore operation could corrupt a backup when, by mistake, a
user specified the source directory to become the target
directory for restoring some files (for example, specifying what
was the backup's
--backup_innodb_data_home_dir
value
as the restore's
--innodb_data_home_dir
value). This
fix prevents the problem by having
mysqlbackup throw an error when the command
options make the source and target file paths the same for any
file copying during a restore.
(Bug #28376873)
While MySQL Server interprets the system variable setting
--innodb_checksum_algorithm=0
to mean
--innodb_checksum_algorithm=crc32
,
a mysqlbackup operation (except for backup)
failed when
--innodb_checksum_algorithm=0
was set as a configuration option on the backed up server. With
this fix, mysqlbackup now takes
--innodb_checksum_algorithm=0
as valid and interprets it as
--innodb_checksum_algorithm=crc32
.
(Bug #28295519)
A restore operation failed with the error that the binary log index file could not be opened if the binary log base name for the backed-up server was a substring of the word “index”. (Bug #28127023)
mysqlbackup tried to connect to a remote host
specified by the --host
option,
while it was supposed to ignore the option (see
Connection Options for details). With this
fix, the option is now ignored.
As a side-effect of this change, on Unix-like platforms,
mysqlbackup command that used the
--host
option now needs to use the
--protocol=TCP
option to indicate
explicitly that mysqlbackup is to connect
to localhost
using TCP/IP.
(Bug #25911987)
When the option --no-locking
was
used during a backup operation, the backup sometimes failed with
mysqlbackup complaining that the highest LSN
was larger in a copied page than on the backed-up server. It was
because mysqlbackup did not perform a log
flushing before copying the redo log when the option was used.
With this fix, log flushing was always performed to prevent the
error.
(Bug #25412655)