MySQL Enterprise Backup 3.12.2 has been released

Dear MySQL users,

MySQL Enterprise Backup v3.12.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 to the MySQL family of products.

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

Changes in MySQL Enterprise Backup 3.12.2      (2016-01-21)

    Functionality Added or Changed

      * If the value for the innodb_checksum_algorithm or
        backup_innodb_checksum_algorithm option provided on the
        mysqlbackup command line differed from that of the
        server, mysqlbackup gave a single warning that the
        checksum algorithm specified might be incompatible with
        the server. Starting with 3.12.2, to be consistent with
        the way checksums are handled by the MySQL server since
        5.6.25, mysqlbackup gives a separate warning for every
        single page of data in every .ibd file for which the
        checksum algorithm specified does not match the one used
        on the server. (Bug #22509993)

      * Values for MASTER_USER and MASTER_PORT are now included
        in the CHANGE MASTER TO statement in the slave
        information file (meta/ibbackup_slave_info) when the
        --slave-info option is used for backing up a slave
        server. (Bug #14213115)

    Bugs Fixed

      * When mysqlbackup came across a file of an unknown file
        type and its path name contained characters that
        mysqlbackup could not convert to the file system
        character set, it threw an error. With this fix,
        mysqlbackup continues with its operation in the situation
        after giving a warning. (Bug #22098742)

      * A backup failed if, towards the end of the backup
        process, mysqlbackup found the binary log file that was
        current at the beginning of the backup had been purged.
        With this fix, mysqlbackup now ignores the fact that the
        file has been purged, resets the log position to the now
        current binary log file, and continues with the backup
        without raising any issues. (Bug #21655145)

      * During a backup, mysqlbackup performed, by default, a SQL
        query to get storage engine information that was to be
        put into the backup_history table. Because the query
        caused all table files on the server to be scanned, it
        consumed a great amount of IO resources when there were
        many tables on the server, resulting in serious
        performance issues sometimes. With this fix, only tables
        included in the backup are scanned, thus reducing the IO
        stress on the server. (Bug #21098174)

      * When creating a compressed backup, mysqlbackup threw an
        error if a table on the server was dropped in the middle
        of the process. With this fix, the dropped table is
        ignored (as it does not need to be restored) and
        mysqlbackup finishes without throwing an error. (Bug
        #21087079)
        References: See also Bug #18358912.

      * When a backup took a long time to perform and the binary
        logs were rotated in the middle of the process,
        mysqlbackup lost track of the binary log files it was
        copying, skipping the second last log file and attempting
        to copy the last one twice; that resulted in a file
        creation error, at which point mysqlbackup quit
        without releasing its lock on the tables in the database.
        With this fix, all binary log files are now copied
        properly, and the lock on the tables is released at the
        end of the backup process as usual. (Bug #20971763)

      * When restoring an incremental backup image, if the binary
        log in the backup was larger than 16MB, the restored
        binary log would become corrupted, as mysqlbackup kept
        overwriting the same 16-MB file again and again with
        binary log contents. With this fix, the binary log is now
        correctly restored and has the same size as it did on the
        backed-up server. (Bug #20915642)

      * A backup of a slave server failed if, during the backup,
        a relay log file got purged from the slave server (for
        example, due to a log file rotation). With this fix,
        backup continues even if mysqlbackup finds a relay log
        file missing. (Bug #20769891, Bug #76312, Bug #21655314,
        Bug #19255925)

      * When the --password option was used without an argument
        with the copy-back-and-apply-log command, mysqlbackup did
        not prompt user for a password, but either took the
        password from the defaults files, or took it to be an
        empty string when no value was specified in the defaults
        files. (Bug #20657939)

      * When the trace level of mysqlbackup messages was greater
        than "0," if the operation command for mysqlbackup was
        invalid or missing, a stack trace and some error messages
        were printed, which made it look like mysqlbackup had
        crashed. With this fix, a new message is now shown before
        the stack trace, to better explain the situation. (Bug
        #20281022)

      * If an incremental backup had already been applied to a
        directory backup with the apply-incremental-backup
        command and the up-to-date backup was then restored to a
        data directory, it was possible to restore the same
        incremental backup again to the data directory using the
        copy-back-and-apply-log command, potentially causing data
        inconsistencies. With this fix, the incremental data can
        be reapplied only when the --force option is used.
        Without the --force option, the copy-back-and-apply-log
        command skips the apply log operation if the incremental
        backup is a directory backup and throws an error if it is
        an image backup. (Bug #18004179)


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.2 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

-- 
MySQL Announce Mailing List
For list archives: http://lists.mysql.com/announce
To unsubscribe:    http://lists.mysql.com/announce