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. A new option, --cloud-par-url, has been introduced for the purpose. See Backing Up to Cloud Storage and Restoring a Backup from Cloud Storage to a MySQL Server for details.

Also, OAuth is no longer supported by MySQL Enterprise Backup for authentication with the OCI Object Storage service. (Bug #31921624, WL #13984)

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. (WL #14039)

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

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 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() function 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 by mysqlbackup, which has been fixed by this patch. (Bug #31331051)

An incremental backup using page tracking 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)