MySQL Forums
Forum List  »  Announcements

MySQL Enterprise Backup 8.0.19 has been released
Posted by: Bjørn Munch
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.

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)

Options: ReplyQuote


Subject
Views
Written By
Posted
MySQL Enterprise Backup 8.0.19 has been released
1160
January 13, 2020 07:00AM


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.