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
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
validateto test a backup image without extracting. For example:
The mysqlbackup option
--start-lsnis now optional for incremental backups. If you specify the location of an existing full or incremental backup with the new
--incremental-baseoption, you can omit the
--start-lsnoption 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.Note
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
innodb_log_file_sizeconfiguration 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
--incrementaloption and others with the
Because the incremental backup data format produced by the
--incremental-with-redo-log-onlyoption 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.
By default, all InnoDB and non-InnoDB tables are backed up, along with all the
.frmfiles. While the
.frmfiles are being copied, the instance is put into a read-only state. With the
--only-innodboption introduced in MySQL Enterprise Backup 3.6, only InnoDB tables are backed up, but you must copy the
.frmfiles manually, and again this stage happens with the instance in a read-only state. The
--only-innodb-with-frmis intended for backups where you can ensure that no
DROP TABLE, or other DDL statements modify the
.frmfiles for InnoDB tables during the backup operation. If the mysqlbackup detects that any of the relevant
.frmfiles was modified or deleted during the backup job, the command halts with an error.
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-environmentoption 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 variables.
Although the intended purpose of the
--sbt-environmentoption 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 backup job.
backupand some combinations of
--src-entryoptions 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 it. An
extractoption with no
--src-entryoption could fail if the target directory did already exist. (Bug #13465782)
When using mysqlbackup with the
copy-backoption, specifying a
--datadiroption with a trailing slash on the directory name could fail with an uninformative error message. This issue only occurred on Windows systems. (Bug #13392053)
A backup operation could fail if the database being backed up contained only views and no tables. (Bug #13359833)
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)
datadiroption in the MySQL configuration file could cause the mysqlbackup command to halt. (Bug #12838474)
During a backup using the
--only-innodboption, an incorrect message was displayed regarding a time interval to copy non-InnoDB files. (Bug #12691358)
Fixed a potential syntax error in the
CHANGE MASTERstatement written to the
ibbackup_slave_infofile by the
--slave-infooption. (Bug #12540081)
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)