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

MySQL Enterprise Backup 8.0.21 is the latest release for MySQL Enterprise Backup. It only supports 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.

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 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 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 'mysqlbackup'@'localhost';
  GRANT CREATE, INSERT, DROP, ALTER ON mysql.backup_sbt_history_new TO 'mysqlbackup'@'localhost';

  See SBT Backup History Table Update for details. (Bug #30537077, WL #13869)

• 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.

  References: See also: Bug #30935456.

• Encrypted InnoDB tables can now be included in partial backups and restores using transportable tablespaces (TTS). (Bug #31796017, WL #13604)

• 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 replica 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. (WL #13869)

• 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. (WL #13869)

• Compressed InnoDB files are now being verified in validate, backup, and backup-to-image operations. (WL #13835)

• Encrypted InnoDB tables are now being verified in validate operations. (WL #13792)

Bugs Fixed

• When a restore failed for a compressed backup because the --compress-method option was used, mysqlbackup did not print a meaningful error message. With this fix, the error message indicates that the option is incompatible with the operation. (Bug #31861826)

• 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 error 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 (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.19), 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 or 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)