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 theFLUSH 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 theextract
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 exceptbackup-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
, orkeyring_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.