Functionality Added or Changed
When using the
option for backup operations, MySQL Enterprise Backup now
displays, besides the number of pages of data skipped, the total
amount of memory saved by using the option.
In order to enhance security for backed up data, MySQL Enterprise Backup now provides encryption function for single-file backups. See Chapter 8, Encryption for Backups and Section 5.1.14, “Encryption Options” for details.
The compression feature of MySQL Enterprise Backup has been enhanced by the addition of two compression algorithms: the LZ4 method (the default for MySQL Enterprise Backup 3.10 and after) and the LZMA method. Because the LZ4 algorithm, though faster, produces larger files than the ZLIB algorithm used in MySQL Enterprise Backup 3.9 and earlier, users of MySQL Enterprise Backup 3.10 will find an increase in the size of the compressed files if they use the default values for the compression options.
was performed repeatedly on a backup without using the
--force option, an error message was
thrown. From MySQL Enterprise Backup release 3.10.0 onward, the
same action just causes a message to be returned, saying the
operation has already been performed.
MySQL Enterprise Backup can now
integrity of a backup directory as well as a backup image file.
The validation function in 3.10 has also become more robust, as
it tries to verify the checksum value of every data page.
MySQL Enterprise Backup 3.10 introduces two new options for partial backup:
--exclude-tables. The new options
are intended for replacing the older options of
--only-innodb-with-frm, which will
be deprecated in the near future.
--help option of the
mysqlbackup command did not display
apply-incremental-backup might fail
with a “probable data corruption on page” error if
the InnoDB tables being backed up were created in Barracuda
format and with the
mysqlbackup could not read the value of
innodb_data_file_path from the server when it
was more than 1024-character long. It was because
mysqlbackup could not read the value from the
configuration files and relied on the
VARIABLES command (which reads no more than 1024
characters) to access the parameter. With this fix,
innodb_data_file_path can now be read from
the configuration files.
A backup taken with both the
--skip-unused-pages options could
not be restored. This was because with
the apply-log operation was always
skipped (the command did nothing to the backup), while the
expansion of the unused pages was part of the
apply-log operation. This fix
separates the expansion from the
apply-log operation, so that the
backup can be restored.
When a database was initialized with
--innodb-file-per-table=0 and had a fixed-size
system tablespace, all non-InnoDB files backed up had zero size.
After a server restoration from an incremental backup with the
mysqlbackup returned a success code even
after a file renaming failed during the restoration process. The
restored server thus failed to start with an assertion error.
This fix makes sure a proper error is thrown when a file
renaming fails during a restoration.
In a replication setup, when a backup was performed on a master,
the modifications of the tables
mysql.backup_progress were propagated to the
slaves, causing a wrong backup status for the slaves to be
registered. This fix makes MySQL Backup Enterprise disable
binary logging by setting set
during a backup on the master, so that the backup information
will not get replicated to the slaves.
used to restore a backup created using the
--skip-unused-pages option (which is
not a supported use case of
Enterprise Backup crashed. This fix makes MySQL Enterprise
Backup throw an error instead.
(Bug #17281069, Bug #17955913)
MySQL Enterprise Backup continued to run even after reporting
--messages-logdir specified a
non-existing directory. This fix makes
mysqlbackup exit gracefully upon the error.
Because the default value for the parameter
innodb_data_file_path had been
changed to “ibdata1:12M:autoextend” since MySQL
5.6.7, during a backup restoration, if the value of the
parameter was not specified in a configuration file or in the
command, mysqlbackup would still use its
default value of “ibdata1:10M:autoextend”, which
would cause the restoration to fail. With this fix,
mysqlbackup will use the value of
innodb_data_file_path as found in
backup-my.cnf file, but will
also issue a warning that, depending on the configuration of the
target server, the user might need to specify a value for the
With binlogging enabled, MySQL does not necessarily flush the
redo log buffer on commit. The behviour might cause MySQL
Enterprise Backup to take an inconsistent backup, with some of
the transactions (those still in the redo log buffer when the
backup was being taken) possibly missing from the backup. With
this fix, MySQL Enterprise Backup maintains the backup's
consistency by performing a
FLUSH ENGINE LOGS
on the database before it records the binglog position and
copies the redo log entries into the backup.
option was used, MySQL Enterprise Backup failed to copy