MySQL Enterprise Backup 4.1.0 has been released

[Karen Langford]

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/
        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/
        en/mysqlbackup.incremental.html#mysqlbackup.optimis
        tic.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
       .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