MySQL Enterprise Backup 3.10.2 has been released (no replies)

Dear MySQL users,

MySQL Enterprise Backup 3.10.2, 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.

A brief summary of the changes in MySQL Enterprise Backup (MEB)
version 3.10.2 is given below.

Changes in MySQL Enterprise Backup 3.10.2 (2014-07-01)

     Security Note

     * 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
       (http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=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.

   Bugs Fixed

     * After a table backed up using the transportable tablespace
       option (--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
       (http://dev.mysql.com/doc/refman/5.6/en/analyze-table.html)
       step towards the end of the restoration process for tables
       backed up with the --use-tts option, in order to update the
       indexes' cardinalities. (Bug #18682317)

     * 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 by the copy-back-and-apply-log operation. This fix has
       the script copied into the data directory of the slave. (Bug
       #18674861)

     * 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. (Bug #18560870)

     * 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
       copy-back-and-apply-log subcommand. It was because
       copy-back-and-apply-log was not able to extract backup-my.cnf
       from the image and get the value for innodb_data_file_path.
       (Bug #18242586)

     * After an apply-log operation was performed on a compressed
       backup (with the --uncompress and --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 copy-back-and-apply-log operation
       than acted on the still existing, raw, compressed file, but
       thought that an apply-log operation 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
       --incremental-base=dir:directory_path 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. (Bug #16249018)

You can also find more information on the contents of this release in the change log:
http://dev.mysql.com/doc/mysql-enterprise-backup/3.10/en/meb-news.html

The complete manual for MEB 3.10.2 is at,
http://dev.mysql.com/doc/mysql-enterprise-backup/3.10/en/index.html

The tool is available for download from Oracle Software Delivery
Cloud (http://edelivery.oracle.com/).

You can also download the binaries from MOS, https://support.oracle.com
Choose the "Patches & Updates" tab, and then use the "Product or Family
(Advanced Search)" feature. If you haven't looked at MEB recently,
please do so now and let us know how MEB works for you.

Your feedback is greatly appreciated!

Please report any problems you have at https://bug.oraclecorp.com/
for the product "MySQL Enterprise Backup"

Thanks,
The MySQL build team at Oracle