MySQL Enterprise Backup 8.0.19 has been released
Posted by: Bjørn Munch
Date: January 13, 2020 07:00AM
Date: January 13, 2020 07:00AM
Dear MySQL users,
MySQL Enterprise Backup 8.0.19, a new version of the online MySQL backup
tool, is now available for download from the My Oracle Support (MOS) website
as our latest GA release. This release will be available on eDelivery (OSDC)
after the next upload cycle. MySQL Enterprise Backup is a commercial
extension to the MySQL family of products.
MySQL Enterprise Backup 8.0.19 supports only the 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,
please use MySQL Enterprise Backup 3.12.
A brief summary of the changes in MySQL Enterprise Backup (MEB)
since the previous version is given below.
MySQL Enterprise Backup 8.0.19, a new version of the online MySQL backup
tool, is now available for download from the My Oracle Support (MOS) website
as our latest GA release. This release will be available on eDelivery (OSDC)
after the next upload cycle. MySQL Enterprise Backup is a commercial
extension to the MySQL family of products.
MySQL Enterprise Backup 8.0.19 supports only the 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,
please use MySQL Enterprise Backup 3.12.
A brief summary of the changes in MySQL Enterprise Backup (MEB)
since the previous version is given below.
Changes in MySQL Enterprise Backup 8.0.19 (2020-01-13)
* Functionality Added or Changed
* Bugs Fixed
Functionality Added or Changed
* 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 'mysqlbacku
p'@'localhost';
GRANT CREATE, INSERT, DROP, ALTER ON mysql.backup_progress_new TO 'mys
qlbackup'@'localhost';
See Appendix E 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
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/mysqlbackup.privileges.html).
* 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
(https://dev.mysql.com/doc/refman/8.0/en/replication-binlog-encryption-key-rotation.html)
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.
* 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
(https://dev.mysql.com/doc/refman/8.0/en/create-table.html),
RENAME TABLE
(https://dev.mysql.com/doc/refman/8.0/en/rename-table.html),
DROP TABLE
(https://dev.mysql.com/doc/refman/8.0/en/drop-table.html),
ALTER TABLE
(https://dev.mysql.com/doc/refman/8.0/en/alter-table.html),
and operations that map to ALTER TABLE
(https://dev.mysql.com/doc/refman/8.0/en/alter-table.html)
like CREATE INDEX
(https://dev.mysql.com/doc/refman/8.0/en/create-index.html))
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:
o Data-at-rest encryption
(https://dev.mysql.com/doc/refman/8.0/en/innodb-data-encryption.html)
o Page-level compression
(https://dev.mysql.com/doc/refman/8.0/en/innodb-page-compression.html)
o Full-text indexing
(https://dev.mysql.com/doc/refman/8.0/en/innodb-fulltext-index.html)
+ The backup is not taken with the following
mysqlbackup features:
o Optimistic backup
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-backup-optimistic.html)
o Transportable tablespace (TTS)
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/glossary.html#glos_transportable_tab
lespace)
o Redo log archiving
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-redo-log-archiving.html)
o Incremental backups with-redo-log-only
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/mysqlbackup.incremental.html#meb-creating-incremental-redo-log-only)
o Incremental backup using page-tracking
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/mysqlbackup.incremental.html#mysqlbackup.page-tracking.incremental)
Bugs Fixed
* 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
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-redo-log-archiving.html)
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)
* 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
(https://dev.mysql.com/doc/refman/8.0/en/keyring-file-plugin.html)
or keyring_encrypted_file
(https://dev.mysql.com/doc/refman/8.0/en/keyring-encrypted-file-plugin.html)
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)
Subject
Views
Written By
Posted
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.