MySQL Enterprise Backup 4.1 Release Notes  /  Changes in MySQL Enterprise Backup 4.1.5 (2022-10-11)

Changes in MySQL Enterprise Backup 4.1.5 (2022-10-11)

Functionality Added or Changed

  • Important Change: For copy-back-and-apply-log and other single-file operations except backup-to-image, when a relative path is specified for the --backup-image option, mysqlbackup takes the path as relative to the current working directory in which the mysqlbackup command is run. (Bug #29128662)

  • The --rename option now works with both full and partial restores:

    (Bug #31947026)

  • When a server using the keyring_file, keyring_encrypted_file, or keyring_aws was backed up, if it did not contain any encrypted InnoDB tables, the keyring file was not included in the backup. That created a problem when, for example, mysqlbackup was used for a server upgrade, in which case the keyring file was not preserved in the process. mysqlbackup now always looks for the keyring data file and copies it when the above-mentioned keyring plugins are active on the server. (Bug #31820564)

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

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

  • An incremental backup failed if binary logging was disabled on the server during the last backup (on which the incremental backup was based on), but was subsequently enabled before the incremental backup was attempted. It was because mysqlbackup did not have the binary log information required to perform the incremental backup. With this fix, mysqlbackup skips copying the binary log for an incremental backup when the backup it is based on does not include the binary log.

    Also, when restoring onto a server an incremental backup that does not contain the binary log, mysqlbackup renames any binary log files that have already been restored onto the server by adding to them the .old extension; the same thing happens when an incremental backup is restored with the --skip-binlog option. (Bug #30043100)

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

  • The --incremental-base option now accepts a new value, history:last_full_backup, which makes it easy to create a differential backup. See the description of --incremental-base for details. (WL #14475)

Bugs Fixed

  • On Windows platform, if the --backup-dir option was not specified for the extract command, mysqlbackup quit unexpectedly. With this fix, an error is thrown instead in the situation. (Bug #34522095)

  • On Windows platforms, when backing up a server with encrypted InnoDB tables that did not use the keyring_encrypted_file plugin, the operation failed when the --defaults-file or --backup-dir option of the mysqlbackup command contained either spaces or a trailing backslash. (Bug #33085629)

  • When an encrypted InnoDB table had been flushed and then dropped right before a backup-and-apply-log operation, the operation might fail with a Keyring service not initialized error. It was because while the encrypted table was not included in the backup, the redo log fragment included in the backup might contain the changes to the table, and the apply log operation failed to apply the changes because the keyring service had never been initialized. With this fix, mysqlbackup initializes the keyring service in the situation. (Bug #32461308)

  • A backup operation was terminated with signal 6 if the backup involved InnoDB tables encrypted using any keyring plugin other than keyring_encrypted_file, but SSL has been disabled for connection to the server. It was because SSL is required for the keyring migration process, which was part of the backup operation. With this fix, before the keyring migration starts, mysqlbackup checks that SSL has been enabled on the server and throws a proper error if it has not. (Bug #32434668)

  • A restore or validate operation for a compressed backup failed with an unexpected end of file error. (Bug #32163271)

  • The --include-tables and --exclude-tables options were ignored during a restore of a TTS backup taken with full locking (i.e., with --use-tts=with-full-locking). (Bug #31947026)

  • The --compress option is ignored in a backup-and-apply-log operation for a TTS backup with full locking (--use-tts=with-full-locking), resulting in a non-compressed backup. (Bug #31913304)

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

  • A partial backup operation in which an excluded table was stored in an external tablespace failed with the complaint that the .ibd file was too big. It was because of the mishandling of the .isl files involved, which has been corrected by this patch. (Bug #31724848)

  • A restore of a compressed backup failed if the backed-up server did not use .ibd as the extension for InnoDB tablespaces. (Bug #31596356)

  • During a backup operation, if mysqlbackup failed with its query for the server status variable Innodb_buffer_pool_dump_status, it ignored the error and then hung. (Bug #31445204)

  • A restore for an incremental backup failed if the full backup it was based on was created with the --skip-relaylog option, but the incremental backup was created without using the option. (Bug #31124611)

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

  • In a backup-and-apply-log operation, the connection to the server was kept open even after the backup phase of the operation was over. With this fix, the connection is closed when the operation enters the apply-log phase, in order to free up resources. (Bug #30012743)

  • When attempt was made to restore a backup created by a higher version of mysqlbackup, the operation failed with mysqlbackup giving a cryptic message. With this fix, the error message explains clearly that the issue is with version incompatibility. (Bug #29873900)

  • When a backup created with the --incremental-with-redo-log-only option was restored, the binary log was missing on the restored server, so the server could not be started. (Bug #29861999)

  • A backup failed when it involved encrypted InnoDB tables and the --skip-unused-pages option was used. (Bug #29861298)

  • When a compressed backup was created with the backup-and-apply-log command and then restored using the copy-back-and-apply-log command, the redo log were missing from the restored server, causing an InnoDB error when the server was started. (Bug #29851603)

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

  • When the server to be backed up has super_read_only=ON, mysqlbackup gave the warning that the backup operation could not be logged even if the --no-history-logging option has already been used with the backup command. This patch removes the unnecessary warning. (Bug #29742011)

  • A backup-and-apply-log operation failed for a TTS backup if the --compress option was used. (Bug #29639871)

  • During a partial backup, mysqlbackup mishandled some tables stored under the data directory as if they were stored in external tablespaces, when both types of tablespaces existed on the server. (Bug #29590235)

  • Restore of an incremental backup failed when the backed-up server contained a partitioned table with partitions stored in different directories and the table was renamed before the incremental backup was taken, if any of the partitions was not altered after the table's name change. It was because mysqlbackup did not recreate all the .isl files for all table partitions after the restore, and this fix corrects the issue. (Bug #29297920)

  • Backups for a server containing encrypted InnoDB tables failed when the server was of 64-bit and mysqlbackup was of 32-bit (or vice versa). It was due to the way keyring files were handled in the situation, which has been fixed by this patch. (Bug #29292085)

  • A backup created on an EL7 platform containing InnoDB tables encrypted with MySQL Enterprise Transparent Data Encryption (TDE) could not be restored to a server on a Solaris platform. It was because in this case, the source and the target platforms of the backup used different byte ordering formats, causing difficulties in loading the encryption key from the backup. This fix prevents the issue by adding detection and conversion utilities for different system architectures. (Bug #28569367)

  • A backup-and-apply-log operation running with the --compress option printed wrong information on the compression and at the wrong time. With this patch, correct information is printed after the compression is finished. (Bug #28428760)

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

  • While changing the system variable innodb_data_file_path on the server in between a full and an incremental backup makes the incremental backup not restorable, mysqlbackup finished the incremental backup successfully under the situation. With this fix, an error is thrown in this case, to avoid the creation of an unrestorable incremental backup. (Bug #27580477)

  • During an incremental backup, even tables that were unchanged were said to be copied in the output messages by mysqlbackup. With this fix, the messages say the tables are being checked instead. (Bug #27576904)

  • After a backup operation, the entry for innodb_buffer_pool_filename appeared twice in the backup-my.cnf file. (Bug #27217884)

  • An apply-log operation on a compressed directory backup created extra .ibd files in the backup directory. (Bug #26920318)


PREV   HOME   UP   NEXT
Related Documentation
MySQL Enterprise Backup 4.1 User's Guide
Download these Release Notes
PDF (US Ltr) - 130.3Kb
PDF (A4) - 131.3Kb