MySQL Enterprise Backup 8.0 Release Notes
MySQL Enterprise Backup 8.0.21 is the latest release for MySQL Enterprise Backup, and supports MySQL Server 8.0.21 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; for MySQL Server 5.6, please use MySQL Enterprise Backup 3.12.
In the documentation for MySQL 8.0.21, we have started changing the term “master” to “source”, the term “slave” to “replica”, the term “whitelist” to “allowlist”, and the term “blacklist” to “blocklist”. There are currently no changes to the product's syntax, so these terms are still present in the documentation where the current code requires their use. See the blog post MySQL Terminology Updates for more information.
For Windows, MSI installer packages for MySQL Enterprise Backup now include a check for the required Visual Studio redistributable package, and produce a message asking the user to install it if it is missing. (Bug #30541398)
Important Change:
The storage engine for the
mysql.backup_sbt_history
table on a backed-up
server has switched from CSV to InnoDB. Also, an auto-increment
primary key id
column has been added to the
table. When working with a Group Replication setup,
mysqlbackup now makes the
backup_sbt_history
table available to all
members of the server group by making sure that the table is
updated on a primary node during each
mysqlbackup operation.
When MySQL Enterprise Backup 8.0.21 or later tries to perform its first full
backup on a database using the SBT API (see
Backing Up to Tape with Oracle Secure Backup for details), it automatically
checks the format of the
mysql.backup_sbt_history
table. If it detects
that the table is in the old format (which means the server has
been upgraded from 8.0.20 or earlier and has been backed up by
MySQL Enterprise Backup before using the SBT API), it attempts
to perform an update on the table automatically. Grant these
privileges, required for the table upgrade, to the
mysqlbackup
user on the server:
GRANT ALTER ON mysql.backup_sbt_history TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP ON mysql.backup_sbt_history_old TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP, ALTER ON mysql.backup_sbt_history_new TO 'mysqlbackup'@'localhost';
See SBT Backup History Table Update for details. (Bug #30537077, WL #13869)
Important Change:
For a backup-to-image
operation,
when a relative path is specified for the
--backup-image
option,
mysqlbackup now interprets the file path
given as relative to the
backup directory.
References: See also: Bug #30935456.
Encrypted InnoDB tables can now be included in partial backups and restores using transportable tablespaces (TTS). (Bug #31796017, WL #13604)
The tool_name
column of the
backup_progress
table on the MySQL server is
now populated with the full mysqlbackup
command that invoked a backup operation.
(Bug #31011043)
The file backup_gtid_executed.sql
was not
included in a TTS backup for a replica server using GTIDs. The
file is now included in a TTS backup as long as the
--slave-info
option is used.
(Bug #30925447)
A backup now fails when a binary or relay log file is purged
while the backup is going on; it also fails when
mysqlbackup
finds a binary log file missing
on the server (however, if a relay log file is missing, the
backup continues).
(Bug #29269039)
Commands for operations on incremental backups
(copy-back
,
copy-back-and-apply-log
,
apply-log
) have been simplified: the
--incremental
option is no longer
needed for those operations.
(WL #13869)
Commands for operations on compressed backups
(copy-back
,
copy-back-and-apply-log
,
apply-log
, etc.) have been
simplified: the --uncompress
option
is no longer needed, except for
extract
and
image-to-backup-dir
operations that
do not use the
--src-entry
option.
(WL #13869)
Compressed InnoDB files are now being verified in
validate
,
backup
, and
backup-to-image
operations.
(WL #13835)
Encrypted InnoDB tables are now being verified in
validate
operations.
(WL #13792)
When a restore failed for a compressed backup because the
--compress-method
option was used,
mysqlbackup did not print a meaningful error
message. With this fix, the error message indicates that the
option is incompatible with the operation.
(Bug #31861826)
When creating an image backup, if the backup directory
(specified with --backup-dir
) was
full, the backup operation still finished, with just a warning.
Trying to restore the backup then caused
mysqlbackup to quit unexpectedly. With this
fix, the backup fails with an error when the backup directory is
full.
(Bug #31370902)
Backups might fail for a MySQL Server 8.0.20 that was upgraded
from an earlier server version, with
mysqlbackup complaining that the first system
tablespace file (ibdata1
usually) was
corrupted. It was due to the way MySQL Server 8.0.20 handled the
system tablespace, which mysqlbackup had not
adapted itself to, causing an error sometimes with an upgraded
server. This patch adjusted mysqlbackup to
work properly with the server.
(Bug #31263411)
When the --src-entry
option was used
with the list-image
command,
mysqlbackup did not reject the option at
once, but finished the command and then threw an
Invalid Argument
error. With the fix,
mysqlbackup threw an Incompatible
Option
error immediately in the situation.
(Bug #31255087)
A restore operation for an incremental backup failed when the
--with-timestamp
option was used.
(Bug #31184454)
An extract
operation failed with
mysqlbackup complaining that there was no
table match when the option
--src-entry
was set to
meta/backup_variables.txt
. With this fix,
mysqlbackup no longer throws an error in the
situation, but prints the message “The src-entry
'backup_variables.txt' is by default extracted to the output
directory”.
(Bug #31180805)
On non-Windows platforms, when the
--force
option was used with a
table-level restore (a
partial restore of selected tables) of a non-TTS backup, the
redo log files on the server were deleted by
mysqlbackup.
(Bug #31173210)
After a MySQL Server containing encrypted InnoDB tables was upgraded from series 5.7 to 8.0, backup operations on it failed with a Keyring Error. It was due to the way the keyring was handled by mysqlbackup in the situation, which has been fixed by this patch. (Bug #31137866)
When the --backup-image
option was
used in a backup
operation for a
directory backup, mysqlbackup ignored the
option and continued to perform a directory backup. With this
fix, mysqlbackup throws an incompatible
option error in the situation.
(Bug #31137103)
mysqlbackup returned an Internal
Error
when a compressed backup created with the
--use-tts=with-full-locking
option
was being restored.
(Bug #31061894)
When backing up a replica server, if some relay log files were missing, the backup was still completed as expected, but mysqlbackup printed out error messages. With this fix, mysqlbackup returns success instead in the situation. (Bug #31059294)
When the --backup-image
option was
used with the backup-and-apply-log
command, mysqlbackup finished the command as
usual, even though the option and the command are not
compatible. With this fix, in the situation,
mysqlbackup, gives a warning that the
--backup-image
option is ignored.
(Bug #31001191)
When a single-file backup was created with the
--with-timestamp
option and a
relative path was specified for
--backup-image
, the image backup was
created under the current working directory (which had been the
expected behavior since release 8.0.19), but not in a
subdirectory that bore the timestamp in its name.
With this fix, the location for the backup in the situation has
been changed: for a backup-to-image
operation, the relative path given with
--backup-image
is now taken as
relative to the backup directory, and if the
--with-timestamp
option is used, the
backup is created under the backup directory in a subdirectory
that bears the timestamp in its name.
(Bug #30935456)
When backing up to a tape through a media management software
(MMS), mysqlbackup always set a default value
of 0000-00-00 00:00:00
for the
file_creation_time
and
file_expiry_time
values for the operation's
entry in the backup_sbt_history
table on the
backed-up server. If the backup failed for some reasons, those
zero values were then written to the table. If, later, the
backup_sbt_history
table was queried in
NO_ZERO_DATE or
NO_ZERO_IN_DATE
SQL mode, the server returned ERROR 1194 (HY000): Table
'backup_sbt_history' is marked as crashed and should be
repaired
. With this fix, in the case of a backup
failure, mysqlbackup writes the current time
during the backup to those values, so the time values will never
be zeros.
(Bug #30275637)
When the --skip-binlog
option was
used with a restore operation of a TTS backup, the operation
failed. With this fix, the option is ignored in the situation.
(Bug #29813666)
When the --compress-method
option
was set to none
, the backup was finished
without compression as expected, but
mysqlbackup printed erroneous compression
information and saved the InnoDB tablespace files with the
.ibz
extension. With this fix, the
described behaviours of mysqlbackup no longer
occur in the situation.
(Bug #29806518)
The --compress-level
option took up
a value of 0
instead of the default value of
1
when the
--compress-method
option was used
without the --compress
option. With
this fix, the default value of the option is always honored (for
the applicable compression methods).
(Bug #29806518)
A restore operation failed for a backup image created with the
backup-dir-to-image
command from a
directory backup, if the backed-up server used a keyring plugin
other than keyring_encrypted_file
for InnoDB
table encryption. It was because the
backup-dir-to-image
operation
mishandled the keyring_kef
file in the
backup, and this patch corrects the problem.
(Bug #27874581)