Security Fix: The linked OpenSSL library for MySQL Enterprise Backup 3.10 has been updated from version 1.0.1g to version 1.0.1h. Versions of OpenSSL prior to and including 1.0.1g are reported to be vulnerable to CVE-2014-0224. (CVE-2014-0224)
Functionality Added or Changed
MySQL Enterprise Backup now supports creation and restoration of single-file backups using a cloud storage. See Section 5.1.15, “Cloud Storage Options” for details.
After a table backed up using the transportable tablespace
--use-tts) was restored to a
server, queries on the table did not make use of its indexes.
That was because the cardinalities of the indexes were not
properly updated after the table's restoration. This fix adds an
ANALYZE TABLE step towards the
end of the restoration process for tables backed up with the
--use-tts option, in order to update
the indexes' cardinalities.
When cloning a slave for a GTID-enabled server using MySQL Enterprise Backup, the
backup_gtid_executed.sql script created
and stored in the backup directory was not copied onto the slave
operation. This fix has the script copied into the data
directory of the slave.
The maximum number of memory buffers that could be created for a
mysqlbackup operation was hard-coded to be
100, making it impossible to set the number of buffers to a
larger value using the
number-of-buffers option. This fix
removes the hard-coded maximum number for buffers.
mysqlbackup threw an error if a table was dropped when the backup process was running. With this fix, the dropped table is ignored (as it does not need to be restored) and mysqlbackup finishes without throwing an error. (Bug #18358912, Bug #71865)
A segmentation fault occurred when a backup image created from a
backup directory was restored using the
It was because
copy-back-and-apply-log was not able
backup-my.cnf from the image and
get the value for
apply-log operation was
performed on a compressed backup (with the
--apply-log options), when a
copy-back-and-apply-log was applied
on the backup, the restored data was inconsistent. That was
because the first operation did not delete the compressed,
.ibz backup file and did not mark the data
as uncompressed at the end of the operation. The subsequent
than acted on the still existing, raw, compressed file, but
thought that an
had already been performed on it. This fix makes
mysqlbackup delete the compressed, raw backup
file once decompression and
apply-log are finished and properly
mark the backup as uncompressed and up-to-date.
(Bug #18005786, Bug #18005732)
After an incremental backup was applied to a full backup, a
second incremental would fail if the same incremental backup
directory was used and if the
option was pointing to the full backup's directory. This was
because MySQL Enterprise Backup checked the end LSN in the full backup directory
against the end LSN in the MySQL history table (which might not
have been updated yet) and failed the process when there was a
mismatch. This fix removes that check, so user in the described
situation can proceed with creating more incremental backups.