This section documents changes and bug fixes that have been
applied in MySQL Enterprise Backup, from version 3.5.1 through
version 3.7.1. MySQL Enterprise Backup 3.7.1 is primarily a
bug-fix release, with one new feature: the
syntax to simplify taking a sequence of incremental backups.
Functionality Added or Changed
New argument syntax for the
--incremental-baseoption makes it simpler to perform a sequence of incremental backups. When you specify the option combination
--incremental --incremental-base=history:last_backup, the mysqlbackup command uses the metadata in the
mysql.backup_historytable to determine the LSN to use as the lower limit of the incremental backup. You no longer need to keep track of the actual LSN (as in the option
--start-lsn=) or even the location of the previous backup (as in the option
--incremental-base=dir:). (Bug #11765316)
innobackupcommands, provided for compatibility with command syntax from earlier releases are deprecated, meaning that they could be removed in a future release. For more information, see Appendix B, Compatibility Information for MySQL Enterprise Backup.
Important Change: When backing up a slave server using the
--slave-infooption, updates could be lost when restoring the backup and starting replication using the command in the
meta/ibbackup_slave_infofile. This issue could arise if the replication SQL thread was not in synch with the replication I/O thread.
Prior to this fix, the workaround for backups with the
--slave-infooption was to stop the I/O thread and wait for the SQL thread to catch up before starting the backup. (Bug #13588571, Bug #15865869)
An error (segmentation fault) could occur when using the Tivoli Storage Manager product for backups, in combination with the SBT interface and associated
--sbt*options for mysqlbackup. (Bug #13738674)
A single-file backup produced on a Linux system could not be extracted on a Windows system. The mysqlbackup command with the
image-to-backup-diroption would fail with the message:
mysqlbackup.exe: ERROR: Could not extract contents of image file.
When mysqlbackup was run with the
--only-innodb-with-frmoption, it incorrectly displayed messages indicating that tables were being locked. The tables were not actually being locked. The fix suppresses the erroneous messages. (Bug #13477573)
If the MySQL server had a low value for the
wait_timeoutconfiguration option, large backups (particularly for large
MyISAMtables) could fail due to timeout errors. The timeout could also prevent the
mysql.backup_progresstable from recording the final details of the failed backup. The fix raises the value of
wait_timeoutto the maximum value within the session opened by the mysqlbackup command. The maximum timeout value is platform-specific: approximately 24 days on Windows systems, and 1 year for other platforms. (Bug #13258784, Bug #13416025, Bug #14468879)
The operation of the
--forceoperation has been fine-tuned and clarified.
--forceallows overwriting InnoDB data and log files in combination with the
apply-incremental-backupoptions, and replacing the image file in combination with the
backup-dir-to-imageoptions. For all other mode options, the
--forceoption is rejected.
It is now possible to perform another
apply-incremental-backup, even after a successful apply operation. Previously, this was not allowed by mysqlbackup. (Bug #12922426)
meta/image_files.xmlwas incorrectly displayed twice when listing the contents of a single-file backup. (Bug #12563349)
Specifying a very large memory limit, such as
--limit-memory=999999, could cause a segmentation fault when running the mysqlbackup command with the
apply-logoption. (Bug #11779864)
enginescolumn in the
mysql.backup_historytable does not correctly reflect the storage engines of the backed-up databases. This has been documented as a current limitation. (Bug #11763818, Bug #56582)
When mysqlbackup is run with the
copy-backoption, now it displays warnings as existing files are overwritten. (Bug #11760714)