MySQL Enterprise Backup 8.0.22 has been released

[Bjørn Munch]

Dear MySQL users,

MySQL Enterprise Backup 8.0.22, 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.22 supports only the MySQL Server 8.0.22.
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.22 (2020-10-19, General
Availability)

   MySQL Enterprise Backup 8.0.22 is the latest release for
   MySQL Enterprise Backup. It only supports MySQL Server
   8.0.21. 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.

     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed


     * MySQL Enterprise Backup now supports cloud backup and
       restore using the Object Storage service of Oracle Cloud
       Infrastructure (OCI) with Pre-Authenticated Request (PAR)
       URLs
(https://docs.cloud.oracle.com/en-us/iaas/Content/Object/Tasks/usingpreauthenticatedrequests.htm).
       A new option, --cloud-par-url, has been introduced for the
       purpose. See Backing Up to Cloud Storage
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-backup-cloud.html)
       and Restoring a Backup from Cloud Storage to a MySQL Server
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/restore-cloud.html)
       for details. Also, OAuth is no longer supported by MySQL
       Enterprise Backup for authentication with the OCI Object
       Storage service. (Bug #31921624)

     * Messages printed by mysqlbackup were sometimes truncated,
       because of the fixed message length. The length of
       messages is now extensible, so messages are no longer
       truncated. (Bug #31433762)

     * MySQL Enterprise Backup now supports S3-compatible cloud
       storage services with a new option --cloud-host, by which
       users can specify the hostname of the storage service.

     * MySQL Enterprise Backup now supports user authentication
       by the server using LDAP. Two new options, --plugin-dir
       and --enable-cleartext-plugin, have been introduced to
       support this feature. See Using LDAP for Server
       Authentication
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-ldap.html)
       for details.

Bugs Fixed


     * When the keyring_file and keyring_udf plugins were
       enabled on a server and a new key was generated, a
       subsequent backup failed. It was because mysqlbackup
       could not copy the generated key, and this patch corrects
       the issue. (Bug #31717154)

     * During a backup, if redo log archiving was disabled on
       the server, mysqlbackup printed the message "Failed to
       start redo log archiving." With this fix, mysqlbackup
       prints instead the more appropriate message "Redo Log
       Archiving is disabled." (Bug #31618079)

     * An optimistic backup failed if an undo log truncation
       took place during the backup. (Bug #31544201)

     * A restore of a compressed backup failed if an undo log
       truncation
(https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html#truncate-undo-tablespace)
       took place on the server during the backup process. (Bug
       #31544087, Bug #31544087)

     * A backup failed with a segmentation fault when the server
       to be backed up was once a member of a Group Replication
       setup that had been dissolved. It was because mysqlbackup
       still attempted to treat the server as a Group
       Replication node, and this patch corrects that. (Bug
       #31507782)

     * When backing up a server that has been upgraded from
       MySQL 5.7 to 8.0, mysqlbackup copied only the first file
       for the InnoDB system tablespace into the backup when
       there were more of them to be copied. (Bug #31485318)

     * A backup failed with mysqlbackup quitting with a
       segmentation fault if the server had redo log archiving
       enabled and then a query for the server status variable
       Innodb_redo_log_enabled failed. (Bug #31483606)

     * In the backup_create.xml file inside the meta folder of a
       backup, the saved options inside the <server_repo_opts>
       section had the backup_ suffix added to their option
       names by mistake. This fix removes the suffix for those
       options. (Bug #31459476)
       References: This issue is a regression of: Bug #31370902.

     * During any extract operation, mysqlbackup printed the
       message "Failed to get file status with error no : 1504."
       As the message might mislead users to think there was an
       error, it has now been removed from the output for trace
       level INFO . (Bug #31453496)

     * When a .idb file of an encrypted partitioned table
       disappeared during a backup operation, mysqlbackup kept
       complaining for 500 seconds that the file had vanished
       until it threw an error. With this fix, mysqlbackup threw
       an error immediately when running into the situation.
       (Bug #31451654)

     * mysqlbackup hung when, during a backup, a parallel DDL
       occurred and some commits on the server failed. It was
       because in the situation, mysqlbackup could not obtain a
       backup lock on the server. With this fix, the attempt to
       obtain the backup lock times out after a while, and
       mysqlbackup continues with the backup. (Bug #31450946)

     * During a backup, if mysqlbackup failed to query from the
       server the undo log information for some reasons, the
       backup failed with a segmentation error. With this fix,
       mysqlbackup proceeds with the rest of the backup process
       when running into the same situation. (Bug #31445229)

     * During a backup operation, if an undo log tablespace was
       deleted right before the final rescan phase of the backup
       operation, mysqlbackup quit unexpectedly. It was due to
       the way mysqlbackup handled undo log information, which
       has been fixed by this patch. (Bug #31445229)

     * During a backup operation, if mysqlbackup failed with its
       query for the server status variable
       Innodb_buffer_pool_dump_status, it ignored the error and
       then hung. (Bug #31445204)

     * When backing up to a tape using Oracle Secure Backup
       (OSB) 12.2.0.1, mysqlbackup was disconnected from the
       server and backup ended with a segmentation fault. (Bug
       #31442335)

     * A MySQL Enterprise Server quit unexpectedly when the
       mysqlbackup component was installed and uninstalled in
       two different client sessions, and the
       mysqlbackup_page_track_set() UDF was invoked from a third
       session. (Bug #31383239)

     * A TTS backup failed if the server to be backed up had a
       full-text index and also a table named fts, and the table
       was matched by the regular expression for the partial
       backup. (Bug #31382819)

     * A backup failed if tables were dropped from the database
       when the backup was running. It was due to the wrong
       timing for applying the backup lock
(https://dev.mysql.com/doc/refman/8.0/en/lock-instance-for-backup.html)
       by mysqlbackup, which has been fixed by
       this patch. (Bug #31331051)

     * An incremental backup using page tracking
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/mysqlbackup.incremental.html#mysqlbackup.page-tracking.incremental)
       sometimes resulted in a corrupted backup if
       DML operations took place on the server during the
       backup. Beyond fixing the issue, this patch also adds
       validation for data pages in a page-tracking incremental
       backup, and makes it possible to run page-tracking
       incremental backups for databases with a multiple-file
       system tablespace. (Bug #31329848)

     * A compressed backup became corrupted when a DDL operation
       took place on the server during the backup process. (Bug
       #31321514)

     * In a backup-and-apply-log operation, the connection to
       the server was kept open even after the backup phase of
       the operation was over. With this fix, the connection is
       closed when the operation enters the apply-log phase, in
       order to free up resources. (Bug #30012743)

     * A backup failed when the server's system variable
       --innodb-data-file-path pointed to a raw partition on the
       hard disk, because in that case, the OS returned a zero
       device size for the raw partition to mysqlbackup. With
       this fix, mysqlbackup took the device size directly from
       the value of --innodb-data-file-path. (Bug #27811936)