This section documents changes and bug fixes that have been applied in MySQL Enterprise Backup, from version 3.5.1 through version 3.7.0.
Functionality Added or Changed
When managing backup data using the SBT interface of products
such as Oracle Secure Backup, you can change certain settings in
the media management software by setting environment variables
that are recognized by the SBT library. The new
--sbt-environment option of the
mysqlbackup command lets you set such
environment variables for the duration of the backup job only,
rather than using a wrapper script to set and unset the
Although the intended purpose of the
--sbt-environment option is to pass environment
variables used by the SBT library, you can set any Unix, Linux,
or Windows environment setting this way for the duration of the
The single-file backup feature now includes checksum
verification to ensure the backup data remains unchanged during
any transfers to other systems. Each file within the backup
image is tested against a checksum calculated using the CRC32
algorithm, either when files are extracted from the backup
image, or using the new mysqlbackup option
validate to test a backup image
without extracting. For example:
By default, all InnoDB and non-InnoDB tables are backed up,
along with all the
.frm files. While the
.frm files are being copied, the instance
is put into a read-only state. With the
--only-innodb option introduced in
MySQL Enterprise Backup 3.6, only InnoDB tables are backed up,
but you must copy the
.frm files manually,
and again this stage happens with the instance in a read-only
--only-innodb-with-frm is intended
for backups where you can ensure that no
DROP TABLE, or other
DDL statements modify the
.frm files for InnoDB tables during the
backup operation. If the mysqlbackup detects
that any of the relevant
.frm files was
modified or deleted during the backup job, the command halts
with an error.
The mysqlbackup option
--start-lsn is now optional for
backups. If you specify the location of an existing full
or incremental backup with the new
--incremental-base option, you can
--start-lsn option and the
mysqlbackup command automatically determines
the appropriate LSN.
For safety, the backup job halts with an error if the LSN information cannot be retrieved, or if there is a mismatch between the LSN recorded in the previous backup and the LSN reported by the MySQL instance.
The mysqlbackup now offers an alternative method of performing incremental backup for InnoDB tables. This technique involves copying the redo log. This backup method is an alternative to the incremental backup of InnoDB tables.
The benefit of this option is a reduction in random I/O during
the backup stage, in favor of sequential I/O. The older
incremental backup technique reads only changed blocks from
the InnoDB data files. If a high proportion of blocks changed,
I/O overhead to read the changed data could limit the
performance benefits of an incremental backup. The new
technique minimizes this I/O overhead by doing sequential
reads to copy the relatively small
ib_logfile*files. The new technique tends
to perform better on systems with big InnoDB tables that
receive frequent updates, broadly distributed within the
tables. If you have small tables, or relatively few changes,
or changes over and over again to the same pages on disk, the
old technique might perform better for you. The backup
information from the redo logs might also take longer to apply
during the apply-log phase. Run benchmarks to determine the
best technique for your workload.
This technique relies on you having sufficient redo log data
to cover the period since the last incremental backup. Because
the InnoDB redo log uses a circular buffer where older entries
eventually are overwritten, make incremental backups
frequently to avoid having older changes unavailable for the
incremental backup. Ensure that the value of the
configuration option is large enough to hold all the changes
to InnoDB data that accumulate between incremental backups.
When you apply the log data from a series incremental backups
to a full backup, the incremental backup data can be produced
using either of the techniques. Some incremental backups could
be produced by the
option and others with the
Because the incremental backup data format produced by the
--incremental-with-redo-log-only option is
different from the format of MySQL Enterprise Backup 3.6 or
3.5, older mysqlbackup versions cannot
perform the apply step on a
redo-log-only backup. If you use the new incremental backup
technique, upgrade the mysqlbackup command
to the latest MySQL Enterprise Backup level on any machines
where you run the apply-log step.
This feature is not available in the ibbackup command, which is intended only for compatibility with the option syntax from MySQL Enterprise Backup 3.5 and the earlier InnoDB Hot Backup product.
Performance work within the mysqlbackup command makes backup jobs faster with less overhead.
Performance of backup-related I/O operations is improved, particularly on Windows, by reusing I/O library code and best practices from the MySQL Server product.
CPU overhead is lessened by reducing the number of memory allocation and deallocation operations.
backup and some combinations of
--src-entry options could fail
depending on the existence or non-existence of target
directories. In most cases, the error was due to a directory not
existing and mysqlbackup failing to create
extract option with no
--src-entry option could fail if the
target directory did already exist.
When using mysqlbackup with the
copy-back option, specifying a
--datadir option with a trailing slash on the
directory name could fail with an uninformative error message.
This issue only occurred on Windows systems.
MySQL Enterprise Backup now does stricter checking of LSN values to prevent the apply step for incremental backups to be carried out in an incorrect order. Now mysqlbackup gives an error if asked to apply an incremental backup that is older than the full backup, or if another incremental backup needs to be applied first. (Bug #13350012)
A backup operation could fail if the database being backed up contained only views and no tables. (Bug #13359833)
datadir option in the MySQL
configuration file could cause the
mysqlbackup command to halt.
During a backup using the
--only-innodb option, an incorrect
message was displayed regarding a time interval to copy
Fixed a potential syntax error in the
MASTER statement written to the
ibbackup_slave_info file by the
Clarified processing of duplicate options. When the same option is specified more than once, the last one takes precedence. This is standard MySQL practice, not an error or warning situation. (Bug #11763378, Bug #56076)