MySQL Enterprise Backup User's Guide (Version 4.1.5)
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.