MySQL Enterprise Backup 3.12.0 has been released

[Sreedhar S]

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
       /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