MySQL Enterprise Backup 8.0.16 has been released

[Bjørn Munch]

MySQL Enterprise Backup 8.0.16, 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.16 supports only the MySQL Server 8.0.16.
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.

A brief summary of the changes in MySQL Enterprise Backup (MEB)
version 8.0.16 is given below.

------

Changes in MySQL Enterprise Backup 8.0.16 (2019-04-25, GA)

     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed


     * mysqlbackup now supports encrypted InnoDB undo logs
(http://dev.mysql.com/doc/refman/8.0/en/innodb-tablespace-encryption.html#innodb-tablespace-encryption-undo-log).
       The encrypted undo tablespaces are handled the same way
       as the encrypted tablespaces for InnoDB tables. See
       Working with Encrypted InnoDB Tablespaces
(http://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-encrypted-innodb.html)
       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:

         1. A backup lock
(http://dev.mysql.com/doc/refman/8.0/en/lock-instance-for-backup.html)
            on the server instance, which
            blocks DDLs (except those on user-created temporary
            tables), but not DMLs on InnoDB tables.

         2. A FLUSH TABLES tbl_name [, tbl_name] ... WITH READ
            LOCK
(http://dev.mysql.com/doc/refman/8.0/en/flush.html#flush-tables-with-read-lock-with-list)
            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.

         3. A brief blocking of logging activities on the
            server, for collecting logging-related information.
       See The Backup Process
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-backup-process)
       for details. The removal of the lock
       on the whole server instance reduces disruption to the
       database service by the backup operation.
       Important
       The change requires that the BACKUP_ADMIN
(http://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_backup-admin)
       and SELECT
(http://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_select)
       privileges on all tables be granted
       to the user by which mysqlbackup connects to the server
       (the BACKUP_ADMIN
(http://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_backup-admin)
       privilege is automatically granted to users with the RELOAD
(http://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_reload)
       privilege when an in-place upgrade to MySQL Server 8.0 from an
       earlier version is performed).

     * mysqlbackup now supports dynamic changes to undo
       tablespaces
       (http://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html)
       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
(http://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-files-backed-up-summary.html#meb_file_undo-log-files)
       for details.

     * 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).

Bugs Fixed


     * 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)

     * 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
(http://dev.mysql.com/doc/refman/8.0/en/sql-mode.html#sqlmode_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)

     * 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)