MySQL Enterprise Backup 8.0.23 has been released

[Bjørn Munch]

Dear MySQL users,

MySQL Enterprise Backup 8.0.23, 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.23 supports only the MySQL Server 8.0.23.
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.23 (2021-01-18, General Availability)

     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed


     * Logging on cloud operations with OCI object storage now
       provides more information. (Bug #32011770)

     * For a cloud backup operation to an Amazon S3-compatible
       storage service, a check on whether the bucket exists on
       the storage service has been added to the beginning of
       the operation. If the specified bucket does not exist,
       mysqlbackup throws an error and quits the operation. (Bug
       #31981595)

     * A new option, --cloud-chunk-size, has been introduced for
       specifying the size of a chunk when chunked transfer is
       enabled for cloud operations. See the description for
       --cloud-chunk-size for details. (Bug #31977600)

     * MySQL Enterprise Backup has extended the types of cloud
       storage services it supports; see Cloud Storage Options
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/backup-cloud-options.html)
       for details.

Bugs Fixed


     * .sdi files were not included in partial backups, even
       when they were matched by the regular expression given in
       the --include-tables option. (Bug #32162426)

     * When an incremental backup was created with redo log only
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/mysqlbackup.incremental.html#meb-creating-incremental-redo-log-only)
       and the redo log portion in it did not
       contain the latest InnoDB checkpoint of the backed-up
       server, after the incremental backup was restored and the
       server was restarted, the server reported that the data
       was corrupted. It was because the restore process
       replaced the redo log files already restored onto the
       server with the redo log data from the incremental
       backup, causing the latest checkpoint already on the
       server to be lost. With this fix, when an incremental
       backup created with redo log only was restored, the redo
       log files already on the server was only appended but
       never replaced, in order to avoid the loss of the latest
       InnoDB checkpoint that has been restored. (Bug #32139949)

     * When a password was not specified with the
       --encrypt-password option for a validate operation,
       mysqlbackup threw an error, complaining that the password
       was missing. With this fix, mysqlbackup prompts for the
       password under the situation. (Bug #32037428)

     * mysqlbackup quit unexpectedly during a restore operation
       if the --datadir option was not used in the restore
       command. With this fix, mysqlbackup throws an error and
       quits gracefully under the same situation. (Bug
       #31947239)

     * A backup using redo log archiving failed, because
       mysqlbackup created a subdirectory under the redo log
       archiving directory (specified in
       innodb_redo_log_archive_dirs) that was accessible to all
       OS users, and that was not allowed. With this fix, a
       subdirectory with the proper permissions is created under
       the situation. (Bug #31926082, Bug #100913)

     * On a Windows platform, when the value of the server's
       system variable innodb_redo_log_archive_dirs was an
       absolute path name without a label, a backup operation
       for the server using redo log archiving failed with an
       internal error. This was due to mysqlbackup
       misinterpreting the path name in the situation. With this
       fix, the path name is now properly interpreted, and if
       the archive does not exist, a proper error is thrown.
       (Bug #31900686)

     * Cloud backups to OpenStack Swift or compatible object
       storage services using HTTP basic authentication failed
       with an HTTP Error 411. (Bug #31847208)

     * After a TTS backup containing partitioned tables and
       encrypted InnoDB tables was restored, a DROP DATABASE
       statement on the restored server failed. (Bug #31847208)

     * An incremental backup taken with redo log only
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/mysqlbackup.incremental.html#meb-creating-incremental-redo-log-only)
       was completed by mysqlbackup without
       throwing an error even if an in-place DDL had taken place
       during the incremental backup. This would cause an
       assertion error when the server was restarted after the
       incremental backup was restored. With this fix,
       mysqlbackup throws an error during an incremental backup
       when an in-place DDL takes place. (Bug #31653902)

     * An image-to-backup-dir operation on a cloud backup failed
       with the complaint by mysqlbackup that it was not a
       supported cloud operation, even though the extract
       command, an alias of image-to-backup-dir, worked. (Bug
       #31453397)