MySQL Enterprise Backup 3.12.0 has been released

Dear MySQL users,

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

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

Functionality Added or Changed               (2015-03-16)

      * MySQL Enterprise Backup now supports cloud backup and
        restore using OpenStack Object Storage ("Swift") 1.0.
        Authentication can be handled either through Swift's own
        TempAuth authentication system or the OpenStack Identity
        Service (Keystone) 2.0. A number of new command options
        have been introduced to support OpenStack Object Storage;
        see Cloud Storage Options
        (http://dev.mysql.com/doc/mysql-enterprise-backup/3.12/en 
<http://dev.mysql.com/doc/mysql-enterprise-backup/3.12/en/backup-cloud-options.html>
/backup-cloud-options.html 
<http://dev.mysql.com/doc/mysql-enterprise-backup/3.12/en/backup-cloud-options.html>), 
for details.

      * MySQL Enterprise Backup now supports table renaming when
        a single table is restored from a backup created using
        transportable tablespace (TTS). See the
        description for the --rename option for details.

      * The --skip-binlog and --skip-relaylog options can now be
        used to skip the copying back of the binary log and relay
        log onto the server during a restore. This is
        particularly useful for users who do not want those logs
        appearing in the restored server's data directory, as
        that is always the location to which mysqlbackup will
        restore them, regardless of their original locations on
        the backed-up server. (Bug #19887998)

      * MySQL Enterprise Backup no longer writes to the
        incremental_base_lsn column in the mysql.backup_history
        table when creating an incremental backup, as the column
        is no longer used by mysqlbackup. Note that the column
        will eventually be dropped from the table in future
        releases of MySQL Enterprise Backup. (Bug #19548604)

      * The --force option can now be used during the restore of
        a full backup to overwrite existing data in a non-empty
        target directory. See the description for the --force
        option for details. (Bug #19266491)

      * The binary log file and relay log files (in the case of a
        slave server) are now compressed when they are being
        included in a compressed backup and decompressed during a
        restore. (Bug #19149210)

    Bugs Fixed

      * Near the end of the second phase of an optimistic backup,
        mysqlbackup rescanned the tables that had already been
        copied in the first, optimistic phase of the backup, and
        tried to copy again any of those tables that had been
        modified since they were first copied; this attempt to
        overwrite the already-copied table by a recopying caused
        a file creation error. With this fix, any such table
        changes are rightfully ignored, as the changes have been
        recorded in the redo log already and will be taken care
        of later by the apply-log operation. (Bug #20583014)

      * Performing a backup-and-apply-log and then a
        copy-back-and-apply-log caused the redo log files to be
        skipped during the restore process and thus missing on
        the restored server. This was because in this non-typical
        sequence of operations, the apply-log step (by which the
        redo log is usually copied) in the
        copy-back-and-apply-log step was skipped, as an apply-log
        operation had already been performed by the
        backup-and-apply-log step. This fix makes sure the
        copying of the redo log files is not skipped in that
        situation. (Bug #20583014)

      * If an incremental image backup contained a large number
        of pages from a single table, the restore of the
        incremental backup using the copy-back-and-apply-log
        command might fail. (Bug #20492274)

      * After a RESET SLAVE statement was executed on a slave
        server, a subsequent backup for the slave server failed
        with an error, as mysqlbackup could not copy the relay
        log file from the server. This was becuase mysqlbackup
        could not detect the location of the current relay log
        after the slave reset, and the this fix makes sure
        mysqlbackup knows how to do that. (Bug #20180440, Bug
        #75074)

      * During the restore of an offline image backup, the
        master.info and relay-log.info files were sometimes not
        copied into the data directory on the target server. (Bug
        #19973192)
        References: This bug is a regression of Bug #19883801.

      * Offline backups failed unless the --skip-binlog option
        was used, because the default action of copying the
        binary log failed. With this fix, the binary log can now
        be successfully included in an offline backup. (Bug
        #19941735)
        References: This bug is a regression of Bug #19883801.

      * When creating a full backup with the --no-locking option,
        mysqlbackup failed to write the binary log information to
        the backup history table and the backup_variables.txt
        file. The result was that when creating an incremental
        backup based on the full backup, the attempt to copy the
        binary log files from the server into the incremental
        backup (which has been the default behavior of MySQL
        Enterprise Backup since 3.11.0) would fail, causing the
        incremental backup to stop. With this fix, the binary log
        information is no longer missing after the full backup,
        so the incremental backup no longer fails." (Bug
        #19915713)

      * If a binary log file on the server got removed as a
        backup was taking place, the backup failed, as
        mysqlbackup could not find the binary log file it wanted
        to copy into the backup. With the fix, mysqlbackup
        continues to finish the backup operation even if some
        binary log files have been deleted, except for the case
        of an incremental backup (for which the backup is still
        going to fail).
        Also, with this fix, only the binary log files listed in
        the binary log index file are copied back to a server
        during a restore, so that purged binary log files, even
        backed up, are not restored. (Bug #19849326)

      * When mysqlbackup encountered a corrupted .frm file during
        a backup, it threw an error, tried to continue with the
        backup, and then hung eventually. With this fix,
        mysqlbackup just gives a warning message ("WARNING: An
        error occurred while adding manifest information for
        backup"), and then continues with the backup as usual.
        (Bug #19608231)

      * On Windows platforms, when symbolic links were involved
        in the file path arguments for options like --backup-dir
        or --backup-image, mysqlbackup failed with an error. With
        this fix, mysqlbackup works in the situation as long as
        the arguments do not involve dangling symbolic links, in
        which case mysqlbackup throws an error instead of
        creating any directory or file under any
        symbolically-linked locations. (Bug #19608231)

      * When trying to restore a non-TTS backup to a running
        server, mysqlbackup overwrote the data on the server
        without giving any warning. This fix makes mysqlbackup
        terminate the restore of a non-TTS full backup with an
        error whenever it finds the target data directory to be
        non-empty, and then issue a message that the --force
        option should be used if the user wants the original data
        to be overwritten.
        Note
        For overwriting the data directory during the restore of
        a full backup using the --force option, users are
        recommended to use the copy-back command, preceded by an
        apply-log operation, instead of using the one-step
        copy-back-and-apply-log command.
        (Bug #19266491)

      * Compression information displayed after the second phrase
        of a compressed, optimistic backup was only for the
        second phase of the backup. With this fix, the
        information now reflects the total compression performed
        for the whole process, including both the first and
        second phases. (Bug #19200562)

      * The list-image operation on cloud backups failed. This
        was because the operation requires transfer of data
        without buffering, but mysqlbackup was transferring data
        in buffered mode by default. This fix makes mysqlbackup
        download data for the operation without buffering---which
        is possible as long as the cloud proxy supports HTTP
        range hearers. (Bug #19162974)

      * When restoring an incremental backup using the
        copy-back-and-apply-log subcommand on Windows platforms,
        the operation failed when long file paths were used in
        the command-line options. (Bug #18448617)

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.12/en/meb-news.html

The complete manual for MEB 3.12.0 is at
http://dev.mysql.com/doc/mysql-enterprise-backup/3.12/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,

On behalf MySQL RE team at Oracle

Sreedhar S