Chapter 3 What's New in MySQL Enterprise Backup 4.1?

This chapter highlights the new features in MySQL Enterprise Backup 4.1, as well as any significant changes made to MySQL Enterprise Backup with the release of this series.

• MySQL Enterprise Backup now supports optimistic incremental backup, in which mysqlbackup scans only those InnoDB data files that have been modified since the last backup for changed pages and then saves them into the incremental backup. It potentially makes incremental backups faster. See Full-scan versus Optimistic Incremental Backup for details.

• A full set of exit codes have now been implemented for MySQL Enterprise Backup. Also, a new mysqlbackup command, print-message, returns an exit message for any given exit code supplied with the new option --error-code. See Section 13.1, “Exit codes of MySQL Enterprise Backup” for details.

• Apply-log operations can now be performed with multiple worker threads in parallel, which can improve performance for the operations. The number of threads to be used can be specified with the --process-threads option.

• MySQL Enterprise Backup now supports the --ssl-mode option, which enables you to specify the security state of the connection to the server. It replaces the client side --ssl and --ssl-verify-server-cert options, which are now deprecated. See the description of the --ssl-mode option in MySQL 5.7 Reference Manual for details.

• A number of measures have been implemented to increase the performance for hot backups by decreasing the duration of the final phase of hot backups in which the server is locked. See the MySQL Enterprise Backup 4.1 Release Notes for details.

• A new option, --skip-final-rescan, makes mysqlbackup skip the final rescan for InnoDB tables that are modified by DDL operations after the database has been locked near the end of a backup operation. See the description for --skip-final-rescan for details.

• The output by mysqlbackup, which goes to the stderr stream and the message log, has now been improved to include the timestamps and thread IDs for all steps taken by mysqlbackup, in order to provide more information for debugging purposes.

• The backup_history table now includes the following new columns:

  • start_time_utc

  • end_time_utc

  • consistency_time_utc

  • meb_version

  • server_uuid (for release 4.1.2 and later)

• For MySQL Enterprise Backup 4.1.1 and later working with MySQL Server 5.7.21 and later: Servers' use of the keyring_encrypted_file and keyring_aws plugins is now supported by MySQL Enterprise Backup. See Chapter 6, Working with Encrypted InnoDB Tables for details.

• For MySQL Enterprise Backup 4.1.1 and later: HTTP Basic Authentication and non-chunked transfer are now supported for backup and restore using OpenStack Swift-compatible object storage services. See Section 16.15, “Cloud Storage Options” for details.

• For MySQL Enterprise Backup 4.1.2 and later: OAuth is now supported for Oracle Cloud Infrastructure Object Storage client authentication. Two new options, --cloud-storage-url and --cloud-oauth-token, have been introduced for the purpose. See Section 16.15, “Cloud Storage Options” for details.

• For MySQL Enterprise Backup 4.1.2 and later: The binary log for a backed-up server, instead of being restored always to the data directory on the target server, is now restored by default to the same location it was found on the backed-up server. It can also be restored to a different location specified with the new --log-bin option.

• For MySQL Enterprise Backup 4.1.2 and later: The relay log for a backed-up replica server, instead of being restored always to the data directory on the target replica server, is now restored by default to the same location it was found on the backed-up replica server. It can also be restored to a different location specified with the new --relay-log option.

• For MySQL Enterprise Backup 4.1.2 and later: When working with a Group Replication setup, mysqlbackup now makes the backup history available to all members of the server group by making sure that the backup_history table is updated on a primary node after each mysqlbackup operation. See Chapter 8, Using MySQL Enterprise Backup with Group Replication for details, including the resulting new user privilege requirement for mysqlbackup to connect to a server, regardless of whether the server belongs to a Group Replication setup.

• For MySQL Enterprise Backup 4.1.2 and later: The storage engine of the mysql.backup_history table on a backed-up server has switched from CSV to InnoDB. See here for the special user privileges required by mysqlbackup for the mandatory table migration to take place.

• For MySQL Enterprise Backup 4.1.3 and later: 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 cannot be used to override the requirement on the three options).

• For MySQL Enterprise Backup 4.1.4 and later:

  • A new option, --lock-wait-retry-count, can now be used to specify the maximum number of retries to be attempted by mysqlbackup after the FLUSH TABLES WITH READ LOCK statement, issued during the final stage of a backup to temporarily put the database into a read-only state, fails due to a timeout. See the description of the option for details.

  • The --uncompress option is now supported for the extract operation, so that files from a compressed single-file backup can now be extracted and uncompressed with a single command.

• For MySQL Enterprise Backup 4.1.5 and later:

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

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

    • If the --include-tables and --exclude-tables options are not used, all tables in the backup are restored, with the table selected by the --rename option renamed as specified.

    • If the --include-tables and --exclude-tables options are used, all tables selected by the two options together are restored, with the table selected by the --rename option renamed as specified.

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

  • Encrypted InnoDB tables can now be included in partial backups and restores using transportable tablespaces (TTS).

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

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

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

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