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
1496
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.