Important Change: New rows (
meb_version) are being added to the
backup_historytable. To effect this change, the ALTER privilege on the
backup_historytable must be granted to the user by which
mysqlbackupconnects to MySQL Server before performing any backup operations with release 3.12.4.
Information on the executed GTIDs is now included in the mysqlbackup output and the backup log when the backed-up server has GTIDs enabled. (Bug #25978803)
A backup became corrupted if, during the backup process, a DDL operation that took advantage of MySQL server's online DDL feature occurred. This was because mysqlbackup did not support the server feature—and it still does not. This fix avoids the error by having mysqlbackup turn the server's system variable
old_alter_tableto “1” at the beginning of a backup if it is “0,” so that any DDL operations that take place during the backup are handled with the old table copy method. mysqlbackup then turns the variable back to “0” near the end of the backup operation.Important
Notice that in cases where mysqlbackup quits unexpectedly and does not turn
old_alter_tableback to its original value, the user will have to turn the value back to “0” manually on the server, in order to return the server to its original configuration. This should be performed if the statement “Server system variable 'old_alter_table' was set to '0'. Setting it to '1'” appears in the early output of mysqlbackup, but the statement “Setting server system variable 'old_alter_table' back to '0'” does not appear before mysqlbackup quits.
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. This potentially shortens the duration for the lock and reduces the backup's impact on the server's normal operation. See the description for
--skip-final-rescanfor details. (Bug #21094221)
The output by mysqlbackup, which goes to the
stderrstream 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. (Bug #20142619)
When there were no tables matching the regular expression specified with the
--include-tablesoption during a backup operation, mysqlbackup still created a backup, which contained an empty folder for each database on the server. mysqlbackup now throws an error when
--include-tablesselects no tables to be backed up. (Bug #18114353)
During the final stage of a backup when MySQL Enterprise Backup tried to temporarily put the database into a read-only state using the
FLUSH TABLES WITH READ LOCKstatement in order to copy non-InnoDB files, if a long query was running on the server at the same time, the
FLUSH TABLES WITH READ LOCKstatement could be taking too long to finish, holding up further queries and eventually bringing down the server.
A new mysqlbackup option
--lock-wait-timeoutcan now be used to specify the timeout in seconds for the FLUSH TABLES WITH READ LOCK statement. If the timeout is exceeded, the statement is failed and the lock on the tables is released, so that queries held up by the lock can then be executed. mysqlbackup then retries the statement and continues with the backup. Default value for
--lock-wait-timeoutis 60 [seconds]. (Bug #14339483)
In order to minimize the impact of a hot backup on the MySQL server, the copying of the buffer pool dump files and some of the metadata files is now performed before the final phase of the backup in which the server instance is locked. This shortens the duration for the lock and reduces the backup's impact on the server's normal operation.
Also, to minimize the resource used on a backup, the copying of the buffer pool dump files is no longer performed for partial and offline backups, for which the buffer pool dump is usually not very useful.
While MySQL Server interprets the system variable setting
--innodb_checksum_algorithm=crc32, a mysqlbackup operation (except for backup) failed when
--innodb_checksum_algorithm=0was set as a configuration option on the backed up server. With this fix, mysqlbackup now takes
--innodb_checksum_algorithm=0as valid and interprets it as
--innodb_checksum_algorithm=crc32. (Bug #28295519)
On macOS, mysqlbackup failed to determine the relay log file name correctly if the relay log index file name was not specified. (Bug #25574605)
Releasenumber for the RPM packages of MySQL Enterprise Backup always said “1,” instead of giving the release number of the Linux distribution for which the package was built. (Bug #25538798)
When the option
--no-lockingwas used during a backup operation, the backup sometimes failed with mysqlbackup complaining that the highest LSN was larger in a copied page than on the backed-up server. It was because mysqlbackup did not perform a log flushing before copying the redo log when either of the mentioned options was used. With this fix, log flushing was always performed to prevent the error. (Bug #25412655)
When creating a full image backup with the
--no-lockingoption, mysqlbackup failed to write the binary log information to the backup history table and the
backup_variables.txtfile. The result was that when creating an incremental image backup based on the full backup, the attempt to copy the binary log files from the server into the incremental image backup (which is the default behavior) would fail, causing the incremental backup to stop. With this fix, the binary log information is no longer missing after the full backup, so the incremental image backup no longer fails." (Bug #25296324)
References: See also: Bug #19915713.
After restoring an incremental backup of a slave server, the file
ibbackup_slave_infowas missing from the
metafolder under the backup directory on the target server. (Bug #25097753)
mysqlbackup logged double entries with wrong information into the
backup_historytable for optimistic backups. (Bug #24502876)
Backups for a slave server in a multi-source replication setup using the
--slave-infooption failed. (Bug #24444950)
References: See also: Bug #21830316.
Attempts to restore an image backup from the cloud using the
--skip-binlogoption failed with a “global tail magic mismatch” error. This was because mysqlbackup failed to perform a non-sequential read from the cloud with gaps caused by the skipping of the binary logs. This fix makes sure mysqlbackup can perform such reads. (Bug #23534700)
extractoperation for an image backup failed with a checksum mismatch error in cases when, during the backup, an InnoDB tablespace file kept growing in size, and mysqlbackup failed to put the correct file size in its file header. (Bug #22905984)
References: This issue is a regression of: Bug #22613568.
apply-incremental-backupoperation on a full backup, mysqlbackup printed to the output stream and the message log file the old instead of the updated binary log position. (Bug #22085034, Bug #78898)
When running the
backup-and-apply-logcommand without a connection to the MySQL server, mysqlbackup could not know the correct binary log file name and binary log position for the backup; yet, at the end of the
backup-and-apply-logoperation, mysqlbackup still printed out some values for the binary log file name and position, which were random in nature. (Bug #21623089)
A backup failed at the step when mysqlbackup applied the
FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCKstatement on all non-InnoDB tables if any table names contained reserved words or special characters. It was because mysqlbackup did not enclose table names in backticks when issuing the statement, and this fix makes sure that is done. (Bug #19709505, Bug #74144)
Occasionally, some files were missing from an image backup created by the
--backup-to-imagecommand. It was due to an internal race condition, which this fix eliminates. (Bug #19600687)