MySQL Enterprise Backup 4.1.0 has been released

Dear MySQL users,

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

MySQL Enterprise Backup 4.1.0 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.1.0 is given below.

Changes in MySQL Enterprise Backup 4.1.0 (2017-03-03)

    Functionality Added or Changed

      * MySQL Enterprise Backup now supports the --ssl-mode
        option, which enables you to specify the security state
        of the connection to the server. It replaces the client
        side --ssl and --ssl-verify-server-cert options, which
        are now deprecated. See the description of the --ssl-mode
        option in MySQL 5.7 Reference Manual
        (http://dev.mysql.com/doc/refman/5.7/en/) for details.
        (Bug #23508228)

      * A new option, --skip-final-rescan, makes mysqlbackup skip
        the final rescan for InnoDB tables that are modified by
        DDL operations after the database has been locked near
        the end of a backup operation. This potentially shortens
        the duration for the lock and reduces the backup's impact
        on the server's normal operation. See the description for
        --skip-final-rescan for details. (Bug #21094221)

      * The output by mysqlbackup, which goes to the stderr
        stream and the message log, has now been improved to
        include the timestamps and thread IDs for all steps taken
        by mysqlbackup, in order to provide more information for
        debugging purposes. (Bug #20142619)

      * During the final stage of a backup when MySQL Enterprise
        Backup tried to temporarily put the database into a
        read-only state using the FLUSH TABLES WITH READ LOCK
        statement in order to copy non-InnoDB files, if a long
        query was running on the server at the same time, the
        FLUSH TABLES WITH READ LOCK statement could be taking too
        long to finish, holding up further queries and eventually
        bringing down the server.
        A new mysqlbackup option --lock-wait-timeout can now be
        used to specify the timeout in seconds for the FLUSH
        TABLES WITH READ LOCK statement. If the timeout is
        exceeded, the statement is failed and the lock on the
        tables is released, so that queries held up by the lock
        can then be executed. mysqlbackup then retries the
        statement and continues with the backup. Default value
        for --lock-wait-timeout is 60 [seconds]. (Bug #14339483)

      * A full set of exit codes have now been implemented for
        MySQL Enterprise Backup. Also, a new mysqlbackup command,
        print-message, returns an exit message for any given exit
        code supplied with the new option --error-code. See Exit
        codes of MySQL Enterprise Backup
        (http://dev.mysql.com/doc/mysql-enterprise-backup/4.1/en/ 
<http://dev.mysql.com/doc/mysql-enterprise-backup/4.1/en/meb-exitcodes.html>
meb-exitcodes.html 
<http://dev.mysql.com/doc/mysql-enterprise-backup/4.1/en/meb-exitcodes.html>) 
for details.

      * To increase the performance for hot backups, mysqlbackup
        now shortens the final phase of the backups by resizing
        the MyISAM key cache before it locks the database with a
        FLUSH TABLES WITH READ LOCK statement. The resize
        triggers a flush of the MyISAM key cache, which reduces
        the time it takes to run the FLUSH TABLES WITH READ LOCK
        statement. The MyISAM key cache size is changed back to
        its original value afterward.

      * Apply-log operations can now be performed with multiple
        worker threads in parallel, which can improve performance
        for the operations. The number of threads to be used can
        be specified with the --process-thread option.

      * The copying of redo log files into backups has been made
        faster, shortening the overall backup time in some cases
        and making it less likely that a backup fails because a
        redo log file has been overwritten before it is copied.

      * MySQL Enterprise Backup now supports optimistic
        incremental backup, in which mysqlbackup scans only those
        InnoDB data files that have been modified since the last
        backup for changed pages and then saves them into the
        incremental backup. It potentially makes incremental
        backups faster, and is performed by specifying
        --incremental=optimistic. See Full-scan versus Optimistic
        Incremental Backup
        (http://dev.mysql.com/doc/mysql-enterprise-backup/4.1/ 
<https://dev.mysql.com/doc/mysql-enterprise-backup/4.0/en/mysqlbackup.incremental.html#mysqlbackup.optimistic.incremental>
en/mysqlbackup.incremental.html#mysqlbackup.optimis 
<https://dev.mysql.com/doc/mysql-enterprise-backup/4.0/en/mysqlbackup.incremental.html#mysqlbackup.optimistic.incremental>
tic.incremental 
<https://dev.mysql.com/doc/mysql-enterprise-backup/4.0/en/mysqlbackup.incremental.html#mysqlbackup.optimistic.incremental>) 
for details.

      * In order to minimize the impact of a hot backup on the
        MySQL server, the copying of the buffer pool dump files
        and some of the metadata files is now performed before
        the final phase of the backup in which the server
        instance is locked. This shortens the duration for the
        lock and reduces the backup's impact on the server's
        normal operation.
        Also, to minimize the resource used on a backup, the
        copying of the buffer pool dump files is no longer
        performed for partial and offline backups, for which the
        buffer pool dump is usually not very useful.

    Bugs Fixed

      * The Release number for the RPM packages of MySQL
        Enterprise Backup always said "1," instead of giving the
        release number of the Linux distribution for which the
        package was built. (Bug #25538798)

      * An apply-log or apply-incremental-backup operation failed
        when, during the time the backup was created, any tables
        have been dropped and then recreated with the same name
        for more than once. (Bug #25334929)

      * When creating a full image 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 image backup based on the full
        backup, the attempt to copy the binary log files from the
        server into the incremental image backup (which is the
        default behavior) 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 image backup no longer fails." (Bug
        #25296324)
        References: See also: Bug #19915713.

      * A backup became corrupted if, during the backup process,
        a DDL operation that took advantage of MySQL server's
        online DDL feature
        (http://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl 
<http://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl.html>
.html <http://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl.html>) 
occurred. This was because mysqlbackup did not
        support the server feature---and it still does not. This
        fix avoids the error by having mysqlbackup turn the
        server's system variable old_alter_table to "1" at the
        beginning of a backup if it is "0," so that any DDL
        operations that take place during the backup are handled
        with the old table copy method. mysqlbackup then turns
        the variable back to "0" near the end of the backup
        operation.
        Notice that in cases where mysqlbackup quits unexpectedly
        and does not turn old_alter_table back to its original
        value, the user will have to turn the value back to "0"
        manually on the server, in order to return the server to
        its original configuration. This should be performed if
        the statement "Server system variable 'old_alter_table'
        was set to '0'. Setting it to '1'" appears in the early
        output of mysqlbackup, but the statement "Setting server
        system variable 'old_alter_table' back to '0'" does not
        appear before mysqlbackup quits. (Bug #25217215)

      * A backup operation sometimes failed due to corruption of
        the copied redo log, and the corruption occurred because
        checksum validation for redo logs was not activated for
        mysqlbackup. This fix restores the checksum function, so
        that the validation is performed when
        innodb_log_checksums=ON on the backed up server. When a
        chuck of redo log data fails the validation, mysqlbackup
        tries to reread the data from the server.
        However, redo log checksum validation is not performed
        for offline backups, and online backups fail when the
        value of innodb_log_checksums is switched off on the
        server when the backup is in progress. (Bug #25057394)

      * In some cases (for example,when the backup could not be
        validated, or when the backup directory could not be
        created), mysqlbackup threw an error when an operation
        failed without creating a message log file. With this
        fix, a message log file is created in those cases. (Bug
        #24678204)

      * mysqlbackup logged double entries with wrong information
        into the backup_history table for optimistic backups.
        (Bug #24502876)

      * Backups for a slave server in a multi-source replication
        setup using the --slave-info option failed. (Bug
        #24444950)
        References: See also: Bug #21830316.

      * If a backed up server was configured with
        innodb_undo_tablespaces being non-zero, during a backup,
        mysqlbackup emitted meaningless warning messages about
        the tablespaces already existing in the cache. This fix
        removes those messages. (Bug #24400230)

      * During an apply-log or a copy-back-and-apply-log
        operation on a backup with encrypted InnoDB tables, if no
        value was specified for the --encrypt-password option
        used, the operation failed with the complaint that no
        encryption password was specified. With this fix,
        mysqlbackup asks the user for the encryption password
        when it is in the same situation. (Bug #24364442)

      * An apply-log operation failed for a backup of a server
        that contained tablespaces outside of its data directory.
        It was because those tablespaces, unlike tablespsaces in
        the data directory, were not loaded by mysqlbackup before
        the apply-log operation started. This fix ensures all
        tablespaces are loaded. (Bug #22026145)

      * When running the backup-and-apply-log command without a
        connection to the MySQL server, mysqlbackup could not
        know the correct binary log file name and binary log
        position for the backup; yet, at the end of the
        backup-and-apply-log operation, mysqlbackup still printed
        out some values for the binary log file name and
        position, which were random in nature. (Bug #21623089)

Thanks,

On behalf MySQL RE team at Oracle
-Sreedhar S