MySQL Enterprise Backup 4.0.1 has been released

Dear MySQL users,

MySQL Enterprise Backup v4.0.1, 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.

MySQL Enterprise Backup v4.0.1 supports only the MySQL server 5.7.9 and 
above.
For any earlier versions of the MySQL server, please use
MySQL Enterprise Backup 3.12 instead.

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

Changes in MySQL Enterprise Backup 4.0.1    (2016-05-26)


    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/4.0/en/
backup-cloud-options.html 
<http://dev.mysql.com/doc/mysql-enterprise-backup/4.0/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)

      * MySQL Enterprise Backup now supports backup of slave
        servers in a multi-source replication setup. (Bug
        #21830316, Bug #22283631)

      * 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
        (http://dev.mysql.com/doc/mysql-enterprise-backup/3.12/en
/advanced.slave-backup-restore.html#meb-temp-tables-sbr 
<http://dev.mysql.com/doc/mysql-enterprise-backup/3.12/en/advanced.slave-backup-restore.html#meb-temp-tables-sbr>)
        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/4.0/en/
backup-compression-options.html 
<http://dev.mysql.com/doc/mysql-enterprise-backup/4.0/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)

      * 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

      * An apply-log operation failed when a RENAME TABLE
        (http://dev.mysql.com/doc/refman/5.7/en/rename-table.html
        ) statement within the redo log was applied to the backup
        even when the renamed table was already included into the
        backup. This fix prevents the problem by making
        mysqlbackup ignore "dirty" (intermediate) log records
        when (a) the new table name is already in used, or (b) if
        the tablespace has not been loaded into memory with the
        old table name. (Bug #23068440)

      * 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)

      * Attempts to restore a compressed image backup using the
        copy-back-and-apply-log command failed with "ERROR:
        InnoDB: Missing MLOG_FILE_NAME or MLOG_FILE_DELETE for
        redo log record ...." It was because the undo tablespaces
        were not loaded, so that the log operations on them
        failed. This fix ensures that the undo tablespaces are
        loaded. (Bug #22914556)

      * If a table had been renamed during a backup operation, it
        sometimes got copied twice into the backup, once under
        its old table name and another time under its new name.
        It was because mysqlbackup, when checking for tables that
        have been changed during the backup process, only checked
        tables by their .ibd file names. With this fix, the
        tablespace ID is also checked, so that a renamed table
        will be recognized as such and will not be copied twice.
        (Bug #22859445)

      * Sometimes, when sizes of the data files kept growing
        during a single-file backup, a broken image backup might
        be produced, causing subsequent commands on it (for
        example, validate or copy-back-and apply-log) to fail. It
        was due to a mismatch of the file size given in the image
        file's header and the actual file size on disk, which is
        now prevented by this fix. (Bug #22613568)

      * Offline backups 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)

      * 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)

      * On Windows platforms, mysqlbackup crashed instead of
        quitting gracefully when the --datadir option was not
        specified for a copy-back or copy-back-and-apply-log
        operation. (Bug #22069093)

      * 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, an
        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 sometimes in serious
        performance issues. 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.

      * 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)

      * 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 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)

Regards

- Sreedhar S