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
MySQL Enterprise Backup now supports the
--ssl-modeoption, which enables you to specify the security state of the connection to the server. It replaces the client side
--ssl-verify-server-certoptions, which are now deprecated. See the description of the
--ssl-modeoption 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
The output by mysqlbackup, which goes to the
stderrstream 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.
backup_historytable now includes the following new columns:
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-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
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
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_historytable 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_historytable 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
--datadirmust be non-existent or empty, mysqlbackup now enforces the same rule for the
--forceoption 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 LOCKstatement, 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.
For MySQL Enterprise Backup 4.1.5 and later:
copy-back-and-apply-logand other single-file operations except
backup-to-image, when a relative path is specified for the
--backup-imageoption, mysqlbackup takes the path as relative to the current working directory in which the mysqlbackup command is run.
--renameoption now works with both full and partial restores:
When a server using the
keyring_awswas 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).
backup_gtid_executed.sqlwas 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-infooption 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
.oldextension; the same thing happens when an incremental backup is restored with the
A backup now fails when a binary or relay log file is purged while the backup is going on; it also fails when
mysqlbackupfinds a binary log file missing on the server (however, if a relay log file is missing, the backup continues).