MySQL Enterprise Backup 8.0 Release Notes
MySQL Enterprise Backup 8.0.19 is the latest release for MySQL Enterprise Backup. It only supports MySQL Server 8.0.19. 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.
Important Change:
For the backup-to-image
,
extract
,
list-image
, and
copy-back-and-apply-log
commands,
any relative path specified with
--backup-image
is now taken to be
relative to the current directory in which the command is run.
(Bug #29943103)
Important Change:
The storage engine for the
mysql.backup_progress
table on a backed-up
server has switched from CSV to InnoDB. Also, an auto-increment
primary key id
column plus a composite index
on the table's backup_id
and
current_timestamp
columns have been added.
When working with a Group Replication setup,
mysqlbackup now makes the
backup_progress
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.19 or later tries to perform its first full
backup on a database, it automatically checks the format of the
mysql.backup_progress
table. If it detects
that the table is in the old format (which means the server has
been upgraded from 8.0.18 or earlier and has been backed up by
MySQL Enterprise Backup before), 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_progress TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP ON mysql.backup_progress_old TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP, ALTER ON mysql.backup_progress_new TO 'mysqlbackup'@'localhost';
See Backup Progress Table Update for details. (Bug #29882544, Bug #28695518)
Important Change:
Due to the added protection for the backups against
inconsistency caused by parallel DDL operations (see discussions
on the new feature below), the user by which
mysqlbackup connects to the MySQL server must
now be granted the SELECT ON *.*
privilege;
see Grant MySQL Privileges to Backup Administrator.
The logging for backup restore has been improved: at the steps for setting the sizes of the log files, the names of the log files are now included. (Bug #30380310)
mysqlbackup now prints a stack trace after being terminated by a signal. (Bug #30042338)
When mysqlbackup fails to connect to a server, the warning returned by mysqlbackup now includes the hostname and port number for TCP connections, and the socket information for socket connections. This is particularly helpful for a Group Replication setup, for which mysqlbackup might attempt to connect to more than one host. (Bug #30040027)
If a binary log file could not be opened during a
non-incremental backup, the backup would still be completed, but
the backup_history
table would indicate the
backup had failed. With this fix, backups of all types fail if
any relevant binary log files could not be opened, and a proper
error is thrown.
(Bug #29882381)
mysqlbackup now includes the configuration
files auto.cnf
and
mysqld-auto.cnf
from a server in its backup
(except for a TTS backup). They are restored to the target
server's data directory as backup-auto.cnf
and backup-mysqld-auto.cnf
respectively. To
use those files to configure your restored server, rename them
to their original names before starting the server.
(Bug #27121423, Bug #30033486)
Master
key rotation for binary log encryption on the server in
between a full and an incremental backup, as well as between two
incremental backups performed by mysqlbackup,
is now supported. During an incremental backup,
mysqlbackup now records encryption
information for all the encrypted binary log files (including
those already backed up in earlier full or incremental backups)
unless the --skip-binlog
option is
used, in which case a warning is given that the older binary log
files might become unrestorable.
Also, the --skip-binlog
option now
makes binary log to be skipped not just for the current backup
operation, but also for all subsequent incremental backups that
are based on the current backup. And when an incremental backup
is restored with the --skip-binlog
option
or when the incremental backup just does not contain the binary
log, mysqlbackup renames any binary log and
index files that have already been restored with the base backup
by adding to them the .old
extension, and
then gives a warning.
In the past, if DDL operations took place when a backup was in progress, the backup might become inconsistent. It is now safe to have DDL operations (CREATE TABLE, RENAME TABLE, DROP TABLE, ALTER TABLE, and operations that map to ALTER TABLE like CREATE INDEX) happening on the server in parallel with a backup operation as long as:
The tables involved exist in their own tablespaces, instead of being in the system tablespace or some general tablespaces.
These server features have not been applied to the tables involved:
The backup is not taken with the following
mysqlbackup
features:
When an image backup was created using the
backup-dir-to-image
command from a
compressed directory backup containing InnoDB tables in the
COMPRESSED row
format, the image backup could not be validated, unless
it was first unpacked back into a directory.
(Bug #31346149)
mysqlbackup reported that an
extract
operation succeeded even if
--src-entry
specified a file that
did not exist in the backup. This fix adds a validation for the
--src-entry
value and makes
mysqlbackup throw an error if the validation
fails.
(Bug #30461566)
During an extract operation, the
extracted file contents did not go into
stdout
as expected when
--dst-entry=-
, but into a file named
“-” instead.
(Bug #30451238)
Sometimes, after receiving a signal 6 due to some errors, mysqlbackup quit without printing any error messages. (Bug #30423128)
mysqlbackup sometimes hung during a backup when redo log archiving had been enabled. It was due to the way mysqlbackup switched between reading the redo log files and the redo log archive, which has been corrected by this fix. (Bug #30387689)
If a tablespace on a server was deleted in the middle of a
backup process and then restored before the end of the process
so that the backup included the table and was successful,
mysqlbackup still reported in the
mysql.backup_history
table that the backup
failed.
(Bug #30340161)
At restart, a restored server someimtes gave the warning
Doublewrite page ### for {space: ###, page_no:###}
could not be restored
. This happened because the
doublewrite buffer, being restored from the backed up server,
contained pages that were no longer relevant. With this fix, the
doublewrite buffer in the backup was cleared during the backup
process, so that it is no longer restored.
(Bug #30286862)
When OpenSSL 1.1.1 was used for connecting mysqlbackup to the server and the --tls-version option was not specified, TLSv1.3 was used, but the output of mysqlbackup indicated it was using TLSv1.2. (Bug #30268505)
Backups for a server using the
keyring_file or
keyring_encrypted_file
plugin failed with the error Opening of file
master_keyring_kef failed
if the keyring file was
located in the server's data directory. This was because in that
case, the plugin returned a path for the keyring file that was
relative to the data directory, with which
mysqlbackup could not locate the file. With
this fix, the plugin returns a full path of the file to
mysqlbackup.
(Bug #30238406)
mysqlbackup quit unexpectedly when the
validate
command was issued without
specifying any command options. With this fix,
mysqlbackup quits gracefully in the situation
by throwing a proper error.
(Bug #30204114)
The default value of the
--page-reread-time
option was 0
millisecond, instead of 100 milliseconds as documented in the
manual.
(Bug #30036877)
When a copy-back-and-apply-log
operation was applied on a prepared backup, the warning
Apply-log operation has already been done on that
backup
appeared twice in the output of
mysqlbackup.
(Bug #29941423)
A backup sometimes failed with mysqlbackup
reporting that an undo log file looked corrupted when the system
variable
innodb_undo_log_encrypt
had
been set to ON
on the server. It was because
the encryption information had not yet propagated to the undo
log file hearer when the file was copied. With this fix, in the
situation, mysqlbackup waited until an undo
log file's header is updated before copying it.
(Bug #29545236)
When restoring an incremental backup, mysqlbackup deleted tables on the server that were not included in the incremental backup. (Bug #29399666)
A backup failed if the server has two external undo tablespaces
on different file paths but with the same file name. This was
because mysqlbackup copied all undo
tablespaces into the same directory during a backup, causing a
file name conflict. With this fix, when copying undo
tablespaces, the pathname of a tablespace relative to
innodb_undo_directory
is
preserved, so there will be no more file name clashes.
(Bug #29340016)
A backup failed at the step when mysqlbackup
applied the FLUSH TABLES tbl_name [, tbl_name] ... WITH
READ LOCK
statement on all non-InnoDB tables if any
table names contained reserved words or special characters. It
was because mysqlbackup did not enclose table
names in backticks when issuing the statement, and this fix
makes sure that is done.
(Bug #19709505, Bug #74144)