MySQL Lists are EOL. Please join:

List:Announcements« Previous MessageNext Message »
From:Sreedhar S Date:February 15 2019 6:01am
Subject:MySQL Enterprise Backup 4.1.3 has been released
View as plain text  
Dear MySQL users,

MySQL Enterprise Backup v4.1.3, a new version of the 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.3 only supports MySQL 5.7.
MySQL Enterprise Backup 3.12.4 only supports MySQL 5.6 and earlier.
MySQL Enterprise Backup 8.0 only supports MySQL 8.0.

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

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

Functionality Added or Changed

      * In addition to the requirement that the target data
        directory for a restore specified by --datadir must
be
        non-existent or empty, mysqlbackup now enforces the
same
        rule for the --innodb_data_home_dir,
        --innodb_log_group_home_dir, and
--innodb_undo_directory
        options (the --force option has no effects on
non-empty
        folders specified by the three options).

Bugs Fixed

      * MySQL Enterprise Backup 4.1 failed to backup a MySQL
        Server that has been backed up by MySQL Enterprise
Backup
        4.0 before. It was due to the way the backup_history
        table was queried, which has now been fixed. (Bug
        #29208386)

      * When working with a Group Replication cluster,
        mysqlbackup might quit unexpectedly near the end of
a
        backup operation when, in order to write to the
        backup_history table, it tried to connect with an
        unencrypted connection to one of the nodes on which
the
        backup user had not logged on before. It happened
when
        the backup user was created with the
        caching_sha2_password plugin
       
(http://dev.mysql.com/doc/refman/5.7/en/caching-sha2-plug 
<http://dev.mysql.com/doc/refman/5.7/en/caching-sha2-pluggable-authentication.html>
gable-authentication.html 
<http://dev.mysql.com/doc/refman/5.7/en/caching-sha2-pluggable-authentication.html>)

plugin, so that it must log on
        with an encrypted connection when it connected to
the
        server for the first time; the attempt to log on
thus
        failed, and mysqlbackup could not handle the
failure.
        With this fix, at such failures, mysqlbackup quits
        gracefully with the warning that the backup
operation is
        finished without updates to the backup history. (Bug
        #28893180)

      * A restore operation could corrupt a backup when, by
        mistake, a user specified the source directory to
become
        the target directory for restoring some files (for
        example, specifying what was the backup's
        --backup_innodb_data_home_dir value as the restore's
        --innodb_data_home_dir value). This fix prevents the
        problem by having mysqlbackup throw an error when
the
        command options make the source and target file
paths the
        same for any file copying during a restore. (Bug
        #28376873)

      * On FreeBSD platforms, using the --show-progress option
        did not make mysqlbackup print progress reports.
(Bug
        #28350122)

      * After encrypted InnoDB tables have been restored,
        sometimes the restored server could not be started,
or
        the encrypted InnoDB tables could not be opened
after the
        server had been started.
        This fix not only resolves the aforementioned
issues, but
        also two other problems: the failure to restore a
backup
        containing encrypted InnoDB tables that were
        row-compressed, and the failure to complete a backup
when
        an encrypted InnoDB table was created in the middle
of
        the backup operation. (Bug #28301281)
        References: See also: Bug #28360241, Bug #27168458.

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

      * The Windows version of MySQL Enterprise Backup did not
        display its build ID when invoked. (Bug #27916702)

      * When the --show-progress=table option was used,
        mysqlbackup gave a warning in the error log on an
aborted
        connection to the server near the end of the
operation.
        It was because the connection to the server for
writing
        to the backup_progress table had remained open. With
this
        fix, the connection is properly closed after the
        mysqlbackup operation is finished. (Bug #27647283)

      * A restore operation for an incremental backup failed when
        individual tablespaces with relative file paths were
        involved. (Bug #26442994)

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

      * Partial backups sometimes failed because full-text index
        files had their file names matched by the regular
        expression provided by the --include-tables option,
and
        the files were then handled as ordinary tablespace
files
        by mysqlbackup. With this fix, mysqlbackup excludes
any
        full-text index files from backups. (Bug #25044900)

      * If, when a backup was in progress and mysqlbackup was
        reading the binary log (or the relay log) index file
and
        the server tried to modify the index file (because,
for
        example, a log flush or log purge just took place),
the
        binary logging (or relay logging) stopped; the
server
        also quit unexpected on Windows platforms. It was
because
        mysqlbackup did not handle well the file sharing
        violation. With this fix, mysqlbackup now reads the
index
        file using the local file system API, which handles
the
        file sharing violation gracefully; also, mysqlbackup
now
        copies the index file into its buffer and then
closes it,
        instead of keeping it open for long, so the server
can
        modify or delete the index file more easily. (Bug
        #22914974, Bug #26047119)

On Behalf of Oracle/MySQL Release Engineering Team,
-Sreedhar S

Thread
MySQL Enterprise Backup 4.1.3 has been releasedSreedhar S19 Feb 2019