MySQL Enterprise Backup 4.1.3 has been released

[Sreedhar Sreedhargadda]

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
       gable-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