Documentation Home
MySQL Enterprise Backup 8.0 Release Notes
Related Documentation
MySQL Enterprise Backup 8.0 User's Guide
Download these Release Notes
PDF (US Ltr) - 315.8Kb
PDF (A4) - 315.4Kb
MySQL Enterprise Backup 8.0 Release Notes  /  Changes in MySQL Enterprise Backup 8.0.19 (2020-01-13, General Availability)

Changes in MySQL Enterprise Backup 8.0.19 (2020-01-13, General Availability)

MySQL Enterprise Backup 8.0.19 is the latest release for MySQL Enterprise Backup, and supports MySQL Server 8.0.19 only. 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; for MySQL Server 5.6 and 5.5, please use MySQL Enterprise Backup 3.12.

Functionality Added or Changed

  • Important Change: For the backup-to-image, extract, list-image, and copy-back-and-apply-log commands, any relative path specified with --backup-image is now taken to be relative to the current directory in which the command is run. (Bug #29943103)

  • Important Change: The storage engine for the mysql.backup_progress table on a backed-up server has switched from CSV to InnoDB. Also, an auto-increment primary key id column plus a composite index on the table's backup_id and current_timestamp columns have been added. When working with a Group Replication setup, mysqlbackup now makes the backup_progress 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.19 or later tries to perform its first full backup on a database, it automatically checks the format of the mysql.backup_progress table. If it detects that the table is in the old format (which means the server has been upgraded from 8.0.18 or earlier and has been backed up by MySQL Enterprise Backup before), 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_progress TO 'mysqlbackup'@'localhost';
GRANT CREATE, INSERT, DROP ON mysql.backup_progress_old TO 'mysqlbackup'@'localhost';
GRANT CREATE, INSERT, DROP, ALTER ON mysql.backup_progress_new TO 'mysqlbackup'@'localhost';

    See Backup Progress Table Update for details. (Bug #29882544, Bug #28695518, WL #13390)

  • Important Change: Due to the added protection for the backups against inconsistency caused by parallel DDL operations (see discussions on the new feature below), the user by which mysqlbackup connects to the MySQL server must now be granted the SELECT ON *.* privilege; see Grant MySQL Privileges to Backup Administrator.

  • The logging for backup restore has been improved: at the steps for setting the sizes of the log files, the names of the log files are now included. (Bug #30380310)

  • mysqlbackup now prints a stack trace after being terminated by a signal. (Bug #30042338)

  • When mysqlbackup fails to connect to a server, the warning returned by mysqlbackup now includes the hostname and port number for TCP connections, and the socket information for socket connections. This is particularly helpful for a Group Replication setup, for which mysqlbackup might attempt to connect to more than one host. (Bug #30040027)

  • If a binary log file could not be opened during a non-incremental backup, the backup would still be completed, but the backup_history table would indicate the backup had failed. With this fix, backups of all types fail if any relevant binary log files could not be opened, and a proper error is thrown. (Bug #29882381)

  • mysqlbackup now includes the configuration files auto.cnf and mysqld-auto.cnf from a server in its backup (except for a TTS backup). They are restored to the target server's data directory as backup-auto.cnf and backup-mysqld-auto.cnf respectively. To use those files to configure your restored server, rename them to their original names before starting the server. (Bug #27121423, Bug #30033486, WL #13413)

  • Master key rotation for binary log encryption on the server in between a full and an incremental backup, as well as between two incremental backups performed by mysqlbackup, is now supported. During an incremental backup, mysqlbackup now records encryption information for all the encrypted binary log files (including those already backed up in earlier full or incremental backups) unless the --skip-binlog option is used, in which case a warning is given that the older binary log files might become unrestorable.

    Also, the --skip-binlog option now makes binary log to be skipped not just for the current backup operation, but also for all subsequent incremental backups that are based on the current backup. And when an incremental backup is restored with the --skip-binlog option or when the incremental backup just does not contain the binary log, mysqlbackup renames any binary log and index files that have already been restored with the base backup by adding to them the .old extension, and then gives a warning. (WL #13329)

  • In the past, if DDL operations took place when a backup was in progress, the backup might become inconsistent. It is now safe to have DDL operations (CREATE TABLE, RENAME TABLE, DROP TABLE, ALTER TABLE, and operations that map to ALTER TABLE like CREATE INDEX) happening on the server in parallel with a backup operation as long as:

    (WL #10222)

Bugs Fixed

  • When an image backup was created using the backup-dir-to-image command from a compressed directory backup containing InnoDB tables in the COMPRESSED row format, the image backup could not be validated, unless it was first unpacked back into a directory. (Bug #31346149)

  • mysqlbackup reported that an extract operation succeeded even if --src-entry specified a file that did not exist in the backup. This fix adds a validation for the --src-entry value and makes mysqlbackup throw an error if the validation fails. (Bug #30461566)

  • During an extract operation, the extracted file contents did not go into stdout as expected when --dst-entry=-, but into a file named “-” instead. (Bug #30451238)

  • Sometimes, after receiving a signal 6 due to some errors, mysqlbackup quit without printing any error messages. (Bug #30423128)

  • mysqlbackup sometimes hung during a backup when redo log archiving had been enabled. It was due to the way mysqlbackup switched between reading the redo log files and the redo log archive, which has been corrected by this fix. (Bug #30387689)

  • If a tablespace on a server was deleted in the middle of a backup process and then restored before the end of the process so that the backup included the table and was successful, mysqlbackup still reported in the mysql.backup_history table that the backup failed. (Bug #30340161)

  • At restart, a restored server someimtes gave the warning Doublewrite page ### for {space: ###, page_no:###} could not be restored. This happened because the doublewrite buffer, being restored from the backed up server, contained pages that were no longer relevant. With this fix, the doublewrite buffer in the backup was cleared during the backup process, so that it is no longer restored. (Bug #30286862)

  • When OpenSSL 1.1.1 was used for connecting mysqlbackup to the server and the --tls-version option was not specified, TLSv1.3 was used, but the output of mysqlbackup indicated it was using TLSv1.2. (Bug #30268505)

  • Backups for a server using the keyring_file or keyring_encrypted_file plugin failed with the error Opening of file master_keyring_kef failed if the keyring file was located in the server's data directory. This was because in that case, the plugin returned a path for the keyring file that was relative to the data directory, with which mysqlbackup could not locate the file. With this fix, the plugin returns a full path of the file to mysqlbackup. (Bug #30238406)

  • mysqlbackup quit unexpectedly when the validate command was issued without specifying any command options. With this fix, mysqlbackup quits gracefully in the situation by throwing a proper error. (Bug #30204114)

  • The default value of the --page-reread-time option was 0 millisecond, instead of 100 milliseconds as documented in the manual. (Bug #30036877)

  • When a copy-back-and-apply-log operation was applied on a prepared backup, the warning Apply-log operation has already been done on that backup appeared twice in the output of mysqlbackup. (Bug #29941423)

  • A backup sometimes failed with mysqlbackup reporting that an undo log file looked corrupted when the system variable innodb_undo_log_encrypt had been set to ON on the server. It was because the encryption information had not yet propagated to the undo log file hearer when the file was copied. With this fix, in the situation, mysqlbackup waited until an undo log file's header is updated before copying it. (Bug #29545236)

  • When restoring an incremental backup, mysqlbackup deleted tables on the server that were not included in the incremental backup. (Bug #29399666)

  • A backup failed if the server has two external undo tablespaces on different file paths but with the same file name. This was because mysqlbackup copied all undo tablespaces into the same directory during a backup, causing a file name conflict. With this fix, when copying undo tablespaces, the pathname of a tablespace relative to innodb_undo_directory is preserved, so there will be no more file name clashes. (Bug #29340016)

  • A backup failed at the step when mysqlbackup applied the FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK statement on all non-InnoDB tables if any table names contained reserved words or special characters. It was because mysqlbackup did not enclose table names in backticks when issuing the statement, and this fix makes sure that is done. (Bug #19709505, Bug #74144)


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