MySQL Enterprise Backup 3.12 Release Notes
Important Change:
New rows (start_time_utc
,
end_time_utc
,
consistency_time_utc
, and
meb_version
) are being added to the
backup_history
table. To effect this change,
the ALTER privilege on the backup_history
table must be granted to the user by which
mysqlbackup
connects 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_table
to
“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.
Notice that in cases where mysqlbackup
quits unexpectedly and does not turn
old_alter_table
back 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.
(Bug #25217215)
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-rescan
for details.
(Bug #21094221)
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.
(Bug #20142619)
When there were no tables matching the regular expression
specified with the --include-tables
option 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-tables
selects 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 LOCK
statement 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
LOCK
statement could be taking too long to finish,
holding up further queries and eventually bringing down the
server.
A new mysqlbackup option
--lock-wait-timeout
can 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-timeout
is 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=0
to mean
--innodb_checksum_algorithm=crc32
,
a mysqlbackup operation (except for backup)
failed when
--innodb_checksum_algorithm=0
was set as a configuration option on the backed up server. With
this fix, mysqlbackup now takes
--innodb_checksum_algorithm=0
as 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)
The Release
number 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
--only-innodb-with-frm
or
--no-locking
was 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-locking
option,
mysqlbackup failed to write the binary log
information to the backup history table and the
backup_variables.txt
file. 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_info
was missing from
the meta
folder under the backup directory
on the target server.
(Bug #25097753)
mysqlbackup logged double entries with wrong
information into the backup_history
table for
optimistic backups.
(Bug #24502876)
Backups for a slave server in a multi-source replication setup
using the --slave-info
option
failed.
(Bug #24444950)
References: See also: Bug #21830316.
Attempts to restore an image backup from the cloud using the
--skip-binlog
option 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)
An extract
operation 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.
After an apply-incremental-backup
operation 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-log
command 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-log
operation,
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 LOCK
statement 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-image
command. It was due to an internal race condition, which this
fix eliminates.
(Bug #19600687)