MySQL Enterprise Backup 8.0.21 has been released

[Bjørn Munch]

Dear MySQL users,

MySQL Enterprise Backup 8.0.21, 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 8.0.21 supports only the MySQL Server 8.0.21.
For earlier versions of MySQL 8.0, use the MySQL Enterprise Backup
version with the same version number as the server. For MySQL server
5.7, please use MySQL Enterprise Backup 4.1, and for MySQL Server 5.6,
please use MySQL Enterprise Backup 3.12.

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

-----

Changes in MySQL Enterprise Backup 8.0.21 (2020-07-13,
General Availability)

   In the documentation for MySQL 8.0.21, we have started
   changing the term "master" to "source", the term "slave" to
   "replica", the term "whitelist" to "allowlist", and the term
   "blacklist" to "blocklist". There are currently no changes to
   the product's syntax, so these terms are still present in the
   documentation where the current code requires their use. See
   the blog post MySQL Terminology Updates
   (https://mysqlhighavailability.com/mysql-terminology-updates/)
   for more information.

     * Packaging Notes

     * Functionality Added or Changed

     * Bugs Fixed

Packaging Notes


     * For Windows, MSI installer packages for MySQL Enterprise
       Backup now include a check for the required Visual Studio
       redistributable package, and produce a message asking the
       user to install it if it is missing. (Bug #30541398)

Functionality Added or Changed


     * Important Change: The storage engine for the
       mysql.backup_sbt_history table on a backed-up server has
       switched from CSV to InnoDB. Also, an auto-increment
       primary key id column has been added to the table. When
       working with a Group Replication setup, mysqlbackup now
       makes the backup_sbt_history table available to all
       members of the server group by making sure that the table
       is updated on a primary node during each mysqlbackup
       operation.
       When MySQL Enterprise Backup 8.0.21 or later tries to
       perform its first full backup on a database using the SBT
       API (see Backing Up to Tape with Oracle Secure Backup
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-backup-osb.html)
       for details), it automatically
       checks the format of the mysql.backup_sbt_history table.
       If it detects that the table is in the old format (which
       means the server has been upgraded from 8.0.20 or earlier
       and has been backed up by MySQL Enterprise Backup before
       using the SBT API), it attempts to perform an update on
       the table automatically. Grant these privileges, required
       for the table upgrade, to the mysqlbackup user on the
       server:
GRANT ALTER ON mysql.backup_sbt_history TO 'mysqlbackup'@'localhost';
GRANT CREATE, INSERT, DROP ON mysql.backup_sbt_history_old TO 'mysqlba
ckup'@'localhost';
GRANT CREATE, INSERT, DROP, ALTER ON mysql.backup_sbt_history_new TO '
mysqlbackup'@'localhost';
       See Appendix E SBT Backup History Table Update
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/backup-sbt-history-table-update.html)
       for details.

       (Bug #30537077)

     * Important Change: For a backup-to-image operation, when a
       relative path is specified for the --backup-image option,
       mysqlbackup now interprets the file path given as
       relative to the backup directory
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/glossary.html#glos_backup_directory).
       References: See also: Bug #30935456.

     * The tool_name column of the backup_progress table on the
       MySQL server is now populated with the full mysqlbackup
       command that invoked a backup operation. (Bug #31011043)

     * The file backup_gtid_executed.sql was not included in a
       TTS backup for a server using GTIDs. The file is now
       included in a TTS backup as long as the --slave-info
       option is used. (Bug #30925447)

     * A backup now fails when a binary or relay log file is
       purged while the backup is going on; it also fails when
       mysqlbackup finds a binary log file missing on the server
       (however, if a relay log file is missing, the backup
       continues). (Bug #29269039)

     * Commands for operations on incremental backups
       (copy-back, copy-back-and-apply-log, apply-log) have been
       simplified: the --incremental option is no longer needed
       for those operations.

     * Commands for operations on compressed backups (copy-back,
       copy-back-and-apply-log, apply-log, etc.) have been
       simplified: the --uncompress option is no longer needed,
       except for extract and image-to-backup-dir operations
       that do not use the --src-entry option.

     * Compressed InnoDB files are now being verified in
       validate, backup, and backup-to-image operations.

     * Encrypted InnoDB tables are now being verified in
       validate operations.

     * Encrypted InnoDB tables can now be included in partial
       backups and restores using transportable tablespaces
       (TTS)
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/glossary.html#glos_transportable_tablespace).

Bugs Fixed


     * When creating an image backup, if the backup directory
       (specified with --backup-dir) was full, the backup
       operation still finished, with just a warning. Trying to
       restore the backup then caused mysqlbackup to quit
       unexpectedly. With this fix, the backup fails with an
       error when the backup directory is full. (Bug #31370902)

     * Backups might fail for a MySQL Server 8.0.20 that was
       upgraded from an earlier server version, with mysqlbackup
       complaining that the first system tablespace file
       (ibdata1 usually) was corrupted. It was due to the way
       MySQL Server 8.0.20 handled the system tablespace, which
       mysqlbackup had not adapted itself to, causing an error
       sometimes with an upgraded server. This patch adjusted
       mysqlbackup to work properly with the server. (Bug
       #31263411)

     * When the --src-entry option was used with the list-image
       command, mysqlbackup did not reject the option at once,
       but finished the command and then threw an Invalid
       Argument error. With the fix, mysqlbackup threw an
       Incompatible Option error immediately in the situation.
       (Bug #31255087)

     * A restore operation for an incremental backup failed when
       the --with-timestamp option was used. (Bug #31184454)

     * An extract operation failed with mysqlbackup complaining
       that there was no table match when the option --src-entry
       was set to meta/backup_variables.txt. With this fix,
       mysqlbackup no longer throws an eorrr in the situation,
       but prints the message "The src-entry
       'backup_variables.txt' is by default extracted to the
       output directory". (Bug #31180805)

     * On non-Windows platforms, when the --force option was
       used with a table-level restore
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/restore.partial.html)
       (a partial restore of selected
       tables) of a non-TTS backup, the redo log files on the
       server were deleted by mysqlbackup. (Bug #31173210)

     * After a MySQL Server containing encrypted InnoDB tables
       was upgraded from series 5.7 to 8.0, backup operations on
       it failed with a Keyring Error. It was due to the way the
       keyring was handled by mysqlbackup in the situation,
       which has been fixed by this patch. (Bug #31137866)

     * When the --backup-image option was used in a backup
       operation for a directory backup, mysqlbackup ignored the
       option and continued to perform a directory backup. With
       this fix, mysqlbackup throws an incompatible option error
       in the situation. (Bug #31137103)

     * mysqlbackup returned an Internal Error when a compressed
       backup created with the --use-tts=with-full-locking
       option was being restored. (Bug #31061894)

     * When backing up a replica server, if some relay log files
       were missing, the backup was still completed as expected,
       but mysqlbackup printed out error messages. With this
       fix, mysqlbackup returns success instead in the
       situation. (Bug #31059294)

     * When the --backup-image option was used with the
       backup-and-apply-log command, mysqlbackup finished the
       command as usual, even though the option and the command
       are not compatible. With this fix, in the situation,
       mysqlbackup, gives a warning that the --backup-image
       option is ignored. (Bug #31001191)

     * When a single-file backup was created with the
       --with-timestamp option and a relative path was specified
       for --backup-image, the image backup was created under
       the current working directory (which had been the
       expected behavior since release 8.0.18), but not in a
       subdirectory that bore the timestamp in its name.
       With this fix, the location for the backup in the
       situation has been changed: for a backup-to-image
       operation, the relative path given with --backup-image is
       now taken as relative to the backup directory, and if the
       --with-timestamp option is used, the backup is created
       under the backup directory in a subdirectory that bears
       the timestamp in its name. (Bug #30935456)

     * When backing up to a tape through a media management
       software (MMS), mysqlbackup always set a default value of
       0000-00-00 00:00:00 for the file_creation_time and
       file_expiry_time values for the operation's entry in the
       backup_sbt_history table on the backed-up server. If the
       backup failed for some reasons, those zero values were
       then written to the table. If, later, the
       backup_sbt_history table was queried in NO_ZERO_DATE
(https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html#sqlmode_no_zero_date)
       or NO_ZERO_IN_DATE
(https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html#sqlmode_no_zero_in_date)
       SQL mode, the server returned
       ERROR 1194 (HY000): Table 'backup_sbt_history' is marked
       as crashed and should be repaired. With this fix, in the
       case of a backup failure, mysqlbackup writes the current
       time during the backup to those values, so the time
       values will never be zeros. (Bug #30275637)

     * When the --skip-binlog option was used with a restore
       operation of a TTS backup, the operation failed. With
       this fix, the option is ignored in the situation. (Bug
       #29813666)

     * When the --compress-method option was set to none, the
       backup was finished without compression as expected, but
       mysqlbackup printed erroneous compression information and
       saved the InnoDB tablespace files with the .ibz
       extension. With this fix, the described behaviours of
       mysqlbackup no longer occur in the situation. (Bug
       #29806518)

     * The --compress-level option took up a value of 0 instead
       of the default value of 1 when the --compress-method
       option was used without the --compress option. With this
       fix, the default value of the option is always honored
       (for the applicable compression methods). (Bug #29806518)

     * A restore operation failed for a backup image created
       with the backup-dir-to-image command from a directory
       backup, if the backed-up server used a keyring plugin
       other than keyring_encrypted_file for InnoDB table
       encryption. It was because the backup-dir-to-image
       operation mishandled the keyring_kef file in the backup,
       and this patch corrects the problem. (Bug #27874581)