MySQL Enterprise Backup 4.1 Release Notes
Important Change:
For copy-back-and-apply-log
and
other single-file
operations except
backup-to-image
, when a relative
path is specified for the
--backup-image
option,
mysqlbackup takes the path as relative to the
current working directory in which the
mysqlbackup command is run.
(Bug #29128662)
The --rename
option now works with
both full and partial restores:
If the --include-tables
and
--exclude-tables
options are not
used, all tables in the backup are restored, with the table
selected by the --rename
option
renamed as specified.
If the --include-tables
and
--exclude-tables
options are
used, all tables selected by the two options together are
restored, with the table selected by the
--rename
option renamed as
specified.
(Bug #31947026)
When a server using the keyring_file
,
keyring_encrypted_file
, or
keyring_aws
was backed up, if it did not
contain any encrypted InnoDB tables, the keyring file was not
included in the backup. That created a problem when, for
example, mysqlbackup was used for a server
upgrade, in which case the keyring file was not preserved in the
process. mysqlbackup now always looks for the
keyring data file and copies it when the above-mentioned keyring
plugins are active on the server.
(Bug #31820564)
Encrypted InnoDB tables can now be included in partial backups and restores using transportable tablespaces (TTS). (Bug #31796017, WL #13604)
The file backup_gtid_executed.sql
was not
included in a TTS backup for a replica server using GTIDs. The
file is now included in a TTS backup as long as the
--slave-info
option is used.
(Bug #30925447)
An incremental backup failed if binary logging was disabled on the server during the last backup (on which the incremental backup was based on), but was subsequently enabled before the incremental backup was attempted. It was because mysqlbackup did not have the binary log information required to perform the incremental backup. With this fix, mysqlbackup skips copying the binary log for an incremental backup when the backup it is based on does not include the binary log.
Also, when restoring onto a server an incremental backup that
does not contain the binary log, mysqlbackup
renames any binary log files that have already been restored
onto the server by adding to them the .old
extension; the same thing happens when an incremental backup is
restored with the --skip-binlog
option.
(Bug #30043100)
A backup now fails when a binary or relay log file is purged
while the backup is going on; it also fails when
mysqlbackup
finds a binary log file missing
on the server (however, if a relay log file is missing, the
backup continues).
(Bug #29269039)
The --incremental-base
option now
accepts a new value,
history:last_full_backup
, which makes it easy
to create a
differential
backup. See the description of
--incremental-base
for details.
(WL #14475)
On Windows platform, if the
--backup-dir
option was not
specified for the extract
command,
mysqlbackup quit unexpectedly. With this fix,
an error is thrown instead in the situation.
(Bug #34522095)
On Windows platforms, when backing up a server with encrypted
InnoDB tables that did not use the
keyring_encrypted_file
plugin, the operation
failed when the --defaults-file
or
--backup-dir
option of the
mysqlbackup command contained either spaces
or a trailing backslash.
(Bug #33085629)
When an encrypted InnoDB table had been flushed and then dropped
right before a backup-and-apply-log
operation, the operation might fail with a Keyring
service not initialized
error. It was because while
the encrypted table was not included in the backup, the redo log
fragment included in the backup might contain the changes to the
table, and the apply log operation failed to apply the changes
because the keyring service had never been initialized. With
this fix, mysqlbackup initializes the keyring
service in the situation.
(Bug #32461308)
A backup operation was terminated with signal 6 if the backup
involved InnoDB tables encrypted using any keyring plugin other
than keyring_encrypted_file
, but SSL has been
disabled for connection to the server. It was because SSL is
required for the keyring migration process, which was part of
the backup operation. With this fix, before the keyring
migration starts, mysqlbackup checks that SSL
has been enabled on the server and throws a proper error if it
has not.
(Bug #32434668)
A restore or validate operation for a compressed backup failed
with an unexpected end of file
error.
(Bug #32163271)
The --include-tables
and
--exclude-tables
options were
ignored during a restore of a TTS backup taken with full locking
(i.e., with
--use-tts=with-full-locking
).
(Bug #31947026)
The --compress
option is ignored in
a backup-and-apply-log operation
for
a TTS backup with full locking
(--use-tts=with-full-locking
),
resulting in a non-compressed backup.
(Bug #31913304)
When a restore failed for a compressed backup because the
--compress-method
option was used,
mysqlbackup did not print a meaningful error
message. With this fix, the error message indicates that the
option is incompatible with the operation.
(Bug #31861826)
A partial backup operation in which an excluded table was stored
in an external tablespace failed with the complaint that the
.ibd
file was too big. It was because of
the mishandling of the .isl files involved, which has been
corrected by this patch.
(Bug #31724848)
A restore of a compressed backup failed if the backed-up server
did not use .ibd
as the extension for InnoDB
tablespaces.
(Bug #31596356)
During a backup operation, if mysqlbackup
failed with its query for the server status variable
Innodb_buffer_pool_dump_status
,
it ignored the error and then hung.
(Bug #31445204)
A restore for an incremental backup failed if the full backup it
was based on was created with the
--skip-relaylog
option, but the
incremental backup was created without using the option.
(Bug #31124611)
When backing up to a tape through a media management software
(MMS), mysqlbackup always set a default value
of 0000-00-00 00:00:00
for the
file_creation_time
and
file_expiry_time
values for the operation's
entry in the backup_sbt_history
table on the
backed-up server. If the backup failed for some reasons, those
zero values were then written to the table. If, later, the
backup_sbt_history
table was queried in
NO_ZERO_DATE or
NO_ZERO_IN_DATE
SQL mode, the server returned ERROR 1194 (HY000): Table
'backup_sbt_history' is marked as crashed and should be
repaired
. With this fix, in the case of a backup
failure, mysqlbackup writes the current time
during the backup to those values, so the time values will never
be zeros.
(Bug #30275637)
In a backup-and-apply-log
operation,
the connection to the server was kept open even after the backup
phase of the operation was over. With this fix, the connection
is closed when the operation enters the apply-log phase, in
order to free up resources.
(Bug #30012743)
When attempt was made to restore a backup created by a higher version of mysqlbackup, the operation failed with mysqlbackup giving a cryptic message. With this fix, the error message explains clearly that the issue is with version incompatibility. (Bug #29873900)
When a backup created with the
--incremental-with-redo-log-only
option was restored, the binary log was missing on the restored
server, so the server could not be started.
(Bug #29861999)
A backup failed when it involved encrypted InnoDB tables and the
--skip-unused-pages
option was used.
(Bug #29861298)
When a compressed backup was created with the
backup-and-apply-log
command and
then restored using the
copy-back-and-apply-log
command, the
redo log were missing from the restored server, causing an
InnoDB error when the server was started.
(Bug #29851603)
When the --skip-binlog
option was
used with a restore operation of a TTS backup, the operation
failed. With this fix, the option is ignored in the situation.
(Bug #29813666)
When the --compress-method
option
was set to none
, the backup was finished
without compression as expected, but
mysqlbackup printed erroneous compression
information and saved the InnoDB tablespace files with the
.ibz
extension. With this fix, the
described behaviours of mysqlbackup no longer
occur in the situation.
(Bug #29806518)
The --compress-level
option took up
a value of 0
instead of the default value of
1
when the
--compress-method
option was used
without the --compress
option. With
this fix, the default value of the option is always honored (for
the applicable compression methods).
(Bug #29806518)
When the server to be backed up has
super_read_only=ON
,
mysqlbackup gave the warning that the backup
operation could not be logged even if the
--no-history-logging
option has
already been used with the backup command. This patch removes
the unnecessary warning.
(Bug #29742011)
A backup-and-apply-log
operation
failed for a TTS backup if the
--compress
option was used.
(Bug #29639871)
During a partial backup, mysqlbackup mishandled some tables stored under the data directory as if they were stored in external tablespaces, when both types of tablespaces existed on the server. (Bug #29590235)
Restore of an incremental backup failed when the backed-up
server contained a partitioned table with partitions stored in
different directories and the table was renamed before the
incremental backup was taken, if any of the partitions was not
altered after the table's name change. It was because
mysqlbackup did not recreate all the
.isl
files for all table partitions after
the restore, and this fix corrects the issue.
(Bug #29297920)
Backups for a server containing encrypted InnoDB tables failed when the server was of 64-bit and mysqlbackup was of 32-bit (or vice versa). It was due to the way keyring files were handled in the situation, which has been fixed by this patch. (Bug #29292085)
A backup created on an EL7 platform containing InnoDB tables encrypted with MySQL Enterprise Transparent Data Encryption (TDE) could not be restored to a server on a Solaris platform. It was because in this case, the source and the target platforms of the backup used different byte ordering formats, causing difficulties in loading the encryption key from the backup. This fix prevents the issue by adding detection and conversion utilities for different system architectures. (Bug #28569367)
A backup-and-apply-log
operation
running with the --compress
option
printed wrong information on the compression and at the wrong
time. With this patch, correct information is printed after the
compression is finished.
(Bug #28428760)
A restore operation failed for a backup image created with the
backup-dir-to-image
command from a
directory backup, if the backed-up server used a keyring plugin
other than keyring_encrypted_file
for InnoDB
table encryption. It was because the
backup-dir-to-image
operation
mishandled the keyring_kef
file in the
backup, and this patch corrects the problem.
(Bug #27874581)
While changing the system variable
innodb_data_file_path
on the server
in between a full and an incremental backup makes the
incremental backup not restorable,
mysqlbackup finished the incremental backup
successfully under the situation. With this fix, an error is
thrown in this case, to avoid the creation of an unrestorable
incremental backup.
(Bug #27580477)
During an incremental backup, even tables that were unchanged were said to be copied in the output messages by mysqlbackup. With this fix, the messages say the tables are being checked instead. (Bug #27576904)
After a backup operation, the entry for
innodb_buffer_pool_filename
appeared twice in
the backup-my.cnf
file.
(Bug #27217884)
An apply-log
operation on a
compressed directory backup created extra
.ibd
files in the backup directory.
(Bug #26920318)