MySQL Lists are EOL. Please join:

List:Packagers« Previous MessageNext Message »
From:Surabhi Bhat Date:February 15 2019 10:48am
Subject:MySQL Enterprise Backup 3.12.4 has been released
View as plain text  
Dear MySQL users,

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

Changes in MySQL Enterprise Backup 3.12.4 (2019-02-15)

      * Functionality Added or Changed

      * Bugs Fixed

Functionality Added or Changed

      * Information on the executed GTIDs is now includfed in the
        mysqlbackup output and the backup log when the backed-up
        server has GTIDs enabled. (Bug #25978803)

      * A backup became corrupted if, during the backup process,
        a DDL operation that took advantage of MySQL server's
        online DDL feature
        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
        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 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)

      * When there were no tables matching the regular expression
        specified with the --include-tables option during a
        backup operation, mysqlbackup still created a backup,
        which contained an empty folder for each database on the
        server. mysqlbackup now throws an error when
        --include-tables selects no tables to be backed up. (Bug

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

      * 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

      * While MySQL Server interprets the system variable setting
        --innodb_checksum_algorithm=0 to mean
        --innodb_checksum_algorithm=crc32, a mysqlbackup
        operation (except for backup) failed when
        --innodb_checksum_algorithm=0 was set as a configuration
        option. With this fix, mysqlbackup now accepts
        --innodb_checksum_algorithm=0 as valid and interprets it
        as --innodb_checksum_algorithm=crc32. (Bug #28295519)

      * On macOS, mysqlbackup failed to determine the relay log
        file name correctly if the relay log index file name was
        not specified. (Bug #25574605)

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

      * When the option --only-innodb-with-frm or --no-locking
        was used during a backup operation, the backup sometimes
        failed with mysqlbackup complaining that the highest LSN
        was larger in a copied page than on the backed-up server.
        It was because mysqlbackup did not perform a log flushing
        before copying the redo log when either of the mentioned
        options was used. With this fix, log flushing was always
        performed to prevent the error. (Bug #25412655)

      * 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
        References: See also: Bug #19915713.

      * After restoring an incremental backup of a slave server,
        the file ibbackup_slave_info was missing from the meta
        folder under the backup directory on the target server.
        (Bug #25097753)

      * 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
        References: See also: Bug #21830316.

      * Attempts to restore an image backup from the cloud using
        the --skip-binlog option failed with a "global tail magic
        mismatch" error. This was because mysqlbackup failed to
        perform a non-sequential read from the cloud with gaps
        caused by the skipping of the binary logs. This fix makes
        sure mysqlbackup can perform such reads. (Bug #23534700)

      * An extract operation for an image backup failed with a
        checksum mismatch error in cases when, during the backup,
        an InnoDB tablespace file kept growing in size, and
        mysqlbackup failed to put the correct file size in its
        file header. (Bug #22905984)
        References: This issue is a regression of: Bug #22613568.

      * After an apply-incremental-backup operation on a full
        backup, mysqlbackup printed to the output stream and the
        message log file the old instead of the updated binary
        log position. (Bug #22085034, Bug #78898)

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

      * Occasionally, some files were missing from an image
        backup created by the --backup-to-image command. It was
        due to an internal race condition, which this fix
        eliminates. (Bug #19600687)

On Behalf of MySQL Release Engineering Team,
Surabhi Bhat

MySQL Enterprise Backup 3.12.4 has been releasedSurabhi Bhat15 Feb