MySQL Forums
Forum List  »  Announcements

MySQL Enterprise Backup 3.12.2 has been released
Posted by: Sreedhar S
Date: January 20, 2016 11:02PM

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 

Options: ReplyQuote


Subject
Views
Written By
Posted
MySQL Enterprise Backup 3.12.2 has been released
3276
January 20, 2016 11:02PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.