Documentation Home
MySQL Enterprise Backup 8.0 Release Notes
Related Documentation Download these Release Notes
PDF (US Ltr) - 308.9Kb
PDF (A4) - 309.0Kb


MySQL Enterprise Backup 8.0 Release Notes  /  Changes in MySQL Enterprise Backup 8.0.23 (2020-01-18, General Availability)

Changes in MySQL Enterprise Backup 8.0.23 (2020-01-18, General Availability)

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

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 for details. (WL #14298)

Bugs Fixed

  • A restore or validate operation for a compressed backup failed with an unexpected end of file error. (Bug #32163271)

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