List:Packagers« Previous MessageNext Message »
From:karen langford Date:June 30 2014 11:19pm
Subject:MySQL Enterprise Backup 3.10.2 has been released
View as plain text  
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
Thread
MySQL Enterprise Backup 3.10.2 has been releasedkaren langford30 Jun 2014