MySQL Enterprise Backup 8.0.17 has been released
Posted by: Balasubramanian Kandasamy
Date: July 22, 2019 03:10AM
Date: July 22, 2019 03:10AM
Dear MySQL users, MySQL Enterprise Backup 8.0.17, 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.17 supports only the MySQL Server 8.0.17. 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.17 is given below. Changes in MySQL Enterprise Backup 8.0.17 (2019-07-22, General Availability) * Functionality Added or Changed * Bugs Fixed Functionality Added or Changed * Before the current release, when backing up a server that used the keyring_okv (https://dev.mysql.com/doc/refman/8.0/en/keyring-okv-plugin.html) plugin for InnoDB table encryption, mysqlbackup must not be run by a sudo user of its operating system. This restriction has now been removed. (Bug #29020232) * The --datadir option is no longer required for restoring a TTS backup (https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/restore-use-tts.html). If the option is specified and its value does not match with that of the target server, the restore will be aborted. (Bug #28546760) * The --incremental-base option now accepts a new value, history:last_full_backup, which makes it easy to create a differential backup (https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/glossary.html#glos_differential_backup). See the description of --incremental-base for details. * To avoid mysqlbackup failing to catch up with the growing redo log during a backup operation and missing redo log data, mysqlbackup now utilizes redo log archiving (https://dev.mysql.com/doc/refman/8.0/en/innodb-redo-log.html#innodb-redo-log-archiving), a new feature available on MySQL Server 8.0.17. Redo log archiving can be disabled using the new mysqlbackup option --no-redo-log-archive. See Backing up Using Redo Log Archiving (https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-redo-log-archiving.html) for details. * mysqlbackup now supports encrypted InnoDB redo logs (https://dev.mysql.com/doc/refman/8.0/en/innodb-tablespace-encryption.html#innodb-tablespace-encryption-redo-log). The encrypted redo tablespaces are handled the same way as the encrypted tablespaces for InnoDB tables. See Working with Encrypted InnoDB Tablespaces (https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-encrypted-innodb.html) for details. Bugs Fixed * A backup failed when the value of the server's system variable innodb_undo_directory contained in itself the file path for the server's data directory. It was due to a mishandling of the file path prefix of the undo tablespace directory by mysqlbackup, which has been corrected by this fix. (Bug #29849566) * Restore of an incremental backup failed if its base full backup had been restored with the --skip-binlog option. (Bug #29757701) * If a relative path was used with the backup_innodb_data_home_dir option when backing up a server, the whole directory specified by the option was being copied into the target server's data directory during a restore of the backup. Not only was that not the expected behavior of mysqlbackup, but it also made subsequent backups of the server failed when the same argument for backup_innodb_data_home_dir was used again. (Bug #29613025) * When the binary log on the server was more than one level below the data directory on the directory tree, mysqlbackup failed to copy the binary log into a backup. This was due to an error on parsing the path of the binary log directory, which has been corrected by this fix. (Bug #29710251) * During a backup operation, when a table or database name contains a slash (/), mysqlbackup always treated the corresponding tablespace as an external tablespace; if that was not actually the case, restore for the backup was going to fail. With this fix, mysqlbackup checks if the tablespace is really external and then handles it appropriately. (Bug #29472939) * External undo tablespaces were missing after a restore of a backup directory extracted from a backup image using the image-to-backup-dir command. It was because of the mishandling of the tracker file for external tablespaces (https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-files-backed-up-summary.html#meb_file_tablespace-tracker) by the image-to-backup-dir command, which has been corrected by this fix. (Bug #29401027) * While no upgrade path exists between MySQL Enterprise Backup 4.1 and 8.0, an attempt to update the mysqlbackup package from release 4.1.3 to 8.0.16 on Ubuntu failed with the complaint that the update tried to overwrite the installation directory for mysqlbackup. With this fix, package conflict information has been added so that at the same attempt, the old package is uninstalled (with the user's consent) before the new package is installed. (Bug #29314267) * When using MySQL Enterprise Backup 8.0 to back up MySQL Server 5.7, an error was thrown, and the error message suggested a wrong version of MySQL Enterprise Backup to be used for the Server. With this fix, the appropriate version of MySQL Enterprise Backup is suggested. (Bug #29195233) * When backing up a server that used the keyring_okv (https://dev.mysql.com/doc/refman/8.0/en/keyring-okv-plugin.html) plugin for InnoDB table encryption, if the --host, --user and --port options were not specified with the mysqlbackup command via the command line or a configuration file, the backup failed. It was because in that case, mysqlbackup had no values for those options that it could use to connect to the server for keyring operations. With this fix, default values are now set, so that mysqlbackup connects to the server on localhost as root and on port 3306 for keyring operations when those options are not specified. (Bug #29015923) * A copy-back-and-apply-log operation for a compressed backup created using the --backup_innodb_data_home_dir option with a relative file path terminated with signal 6. (Bug #28967141) * mysqlbackup hung during a restore operation when the backup contained more than a hundred InnoDB tablespaces. (Bug #28884254, Bug #29674585) * A restore operation for a compressed backup failed with an unexpected end of file error when the backup was created using --compress-method=zlib and the innodb_page_size was smaller than 16KB. (Bug #28623215) * A backup created on an EL7 platform containing InnoDB tables encrypted with MySQL Enterprise Transparent Data Encryption (TDE) could not be restored to a server on a Solaris platform. It was because in this case, the source and the target platforms of the backup used different byte ordering formats, causing difficulties in loading the encryption key from the backup. This fix prevents the issue by adding detection and conversion utilities for different system architectures. (Bug #28569367) * Using the --uncompress option for restoring a backup not created with the --compress option caused the operation to fail with the error No such file or directory. With this fix, the proper error is thrown in the situation. (Bug #28334690) * A backup failed with the error Log scan was only able to reach... when there was a large amount of DML activities occurring in parallel on the server that was being backed up. (Bug #27555969) * During the InnoDB buffer pool dump in a backup operation, mysqlbackup sometimes reported failure for the dump while it was actually still in progress. The fix prevents the problem by improving the way mysqlbackup checks for the status of the dump. (Bug #27185901)
Subject
Views
Written By
Posted
MySQL Enterprise Backup 8.0.17 has been released
1729
July 22, 2019 03:10AM
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.