MySQL Enterprise Backup 3.12.3 has been released

Dear MySQL users,

MySQL Enterprise Backup v3.12.3, 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.3 is given below.

Changes in MySQL Enterprise Backup 3.12.3      (2016-05-09)

Functionality Added or Changed

      * There are two enhancements on how you can configure SSL
        host authenticate for cloud operations of MySQL
        Enterprise Backup:

           + A CA certificate directory, in addition to the
             default folder of the system, can now be specified
             with the new --cloud-ca-path option.

           + mysqlbackup now supports authentication using a CA
             bundle file, whose path is specified by the new
             --cloud-ca-info option.
        See descriptions for the two new options in Cloud Storage
        Options
        (http://dev.mysql.com/doc/mysql-enterprise-backup/3.12/en
/backup-cloud-options.html 
<http://dev.mysql.com/doc/mysql-enterprise-backup/3.12/en/backup-cloud-options.html>) 
for more information. (Bug
        #22761313)

      * mysqlbackup used to sync all data from the buffer cache
        to the hard disk before closing all tables at the end of
        a backup operation. However, for systems with slow
        storage devices and databases with a huge number of
        tables, the sync would increase the backup time
        significantly. To shorten the backup time for those and
        other cases, starting with this release, the sync is no
        longer performed automatically. Users who want the sync
        to be performed at the end of a backup have to use the
        new --free-os-buffer option.
        (Bug #22561345)

      * To avoid completing a backup of a slave server when
        temporary tables are still open on the slave, which will
        cause the restored slave server to be in an inconsistent
        replication state, mysqlbackup now has a new mechanism
        for ensuring that all temporary tables have already been
        closed before finishing a slave backup. See "Temporary
        tables on statement-based replication (SBR) slave" for
        details. A new option, --safe-slave-backup-timeout, has
        been created for specifying the time mysqlbackup will
        wait for all temporary tables to be closed before it
        times out. (Bug #19158516)

      * The compression options
        (http://dev.mysql.com/doc/mysql-enterprise-backup/3.12/en
/backup-compression-options.html 
<http://dev.mysql.com/doc/mysql-enterprise-backup/3.12/en/backup-compression-options.html>) 
can now be used with
        the backup-and-apply-log operation to create a directory
        backup that is prepared and compressed; the backup can
        then be restored using the copy-back operation and the
        --uncompress option. (Bug #18913565)

      * During a copy-back-and-apply-log or a copy-back
        operation, mysqlbackup now checks that the specified
        values for the innodb_log_files_in_group and
        innodb_log_file_size options match those recorded in the
        backup's backup-my.cnf file, and throws an error if the
        values do not match. This prevents mysqlbackup from
        restoring the backup with the wrong parameters, which
        would result in a restored server that cannot be started.
        (Bug #14751027)

    Bugs Fixed

      * An incremental or compressed backup might fail with an
        end-of-file error if there are large data files that kept
        growing during the backup. It was because, as the data
        files expanded, the write process altered the file sizes,
        which confused the read process for the same files. With
        this fix, file sizes and information on them is now
        properly handled. (Bug #23048004)
        References: This issue is a regression of: Bug #19149210.

      * Restoring a cloud backup sometimes failed with Error 18:
        Transferred a partial file. It was because mysqlbackup
        created wrong range headers for its REST requests for
        partial downloads. (Bug #23035334)

      * mysqlbackup crashed when a validate operation was
        performed on an incremental backup that contained an undo
        tablespace but not a system tablespace. It was because
        mysqlbackup did not handle data files for undo
        tablespaces properly, and this fix corrects that. (Bug
        #22960185)

      * Offline backups using MySQL Enterprise Backup
        sometimes failed, with occasional crashes of
        mysqlbackup. (Bug #22595461)

      * For a backup of a slave server, the file name of the
        master server's binary log and the binary log position
        for starting replication, which were stored in the file
        backup_varaibles.txt in the backup as masterlog_file and
        masterlog_pos, got corrupted when an apply-log or
        copy-back-and-apply-log operation was applied to the
        backup. (Bug #22329306)

      * validate operations for backup images and backup-to-image
        operations left over a temporary folder (/tmp) after the
        operations were over. (Bug #20912357)

      * Backups failed for a server that had once been started
        with the --log-bin option and then restarted without it.
        It was because mysqlbackup, seeing the old binary log
        index file on the server, looked in vain for the current
        binary log files, reported that they could not be found,
        and then quitted. With this fix, mysqlbackup checks if
        binary logging is enabled for the server; if it is not,
        mysqlbackup then skips the copying of the binary log into
        the backup. (Bug #20873010)

  Regards
  -Sreedhar S