MySQL Enterprise Backup 4.1 Release Notes
In addition to the requirement that the target data directory
for a restore specified by the
--datadir
option must be
non-existent or empty, mysqlbackup now
enforces the same rule for the
--innodb_data_home_dir
,
--innodb_log_group_home_dir
, and
--innodb_undo_directory
options (the
--force
option cannot be used to
override the requirement on the three options).
(WL #12665, WL #12407)
MySQL Enterprise Backup 4.1 failed to backup a MySQL Server that
has been backed up by MySQL Enterprise Backup 4.0 before. It was
due to the way the backup_history
table was
queried, which has now been fixed.
(Bug #29208386)
When working with a Group Replication cluster,
mysqlbackup might quit unexpectedly near the
end of a backup operation when, in order to write to the
backup_history
table, it tried to connect
with an unencrypted connection to one of the nodes on which the
backup user had not logged on before. It happened when the
backup user was created with the
caching_sha2_password
plugin plugin, so that it must log on with an encrypted
connection when it connected to the server for the first time;
the attempt to log on thus failed, and
mysqlbackup could not handle the failure.
With this fix, at such failures, mysqlbackup
quits gracefully with the warning that the backup operation is
finished without updates to the backup history.
(Bug #28893180)
Restoring an incremental backup image using the
copy-back-and-apply-log
command
failed with mysqlbackup complaining that the
server repository configuration (including, for example, value
of innodb_data_file_path
) was
unknown for the target server, unless the configuration is
explicitly supplied to mysqlbackup. With this
fix, mysqlbackup gets the required
information from the backup-my.cnf
file
already restored with the base backup of the incremental backup.
(Bug #28411028)
A restore operation could corrupt a backup when, by mistake, a
user specified the source directory to become the target
directory for restoring some files (for example, specifying what
was the backup's
--backup_innodb_data_home_dir
value
as the restore's
--innodb_data_home_dir
value). This
fix prevents the problem by having
mysqlbackup throw an error when the command
options make the source and target file paths the same for any
file copying during a restore.
(Bug #28376873)
On FreeBSD platforms, using the
--show-progress
option did not make
mysqlbackup print progress reports.
(Bug #28350122)
After encrypted InnoDB tables have been restored, sometimes the restored server could not be started, or the encrypted InnoDB tables could not be opened after the server had been started.
This fix not only resolves the aforementioned issues, but also two other problems: the failure to restore a backup containing encrypted InnoDB tables that were row-compressed, and the failure to complete a backup when an encrypted InnoDB table was created in the middle of the backup operation. (Bug #28301281)
References: See also: Bug #28360241, Bug #27168458.
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)
The Windows version of MySQL Enterprise Backup did not display its build ID when invoked. (Bug #27916702)
mysqlbackup
quit unexpectedly when backing up
a MySQL Server of release 4.1.2 or later for the first time if
the ALTER
privilege on the
mysql.backup_history_new
table had not been
granted to the MySQL user with which
mysqlbackup
connected to the server. With
this fix, mysqlbackup
quits gracefully in the
situation after throwing the proper error.
Also, the CREATE
,
INSERT
, and
DROP
privileges on
mysql.backup_history_old
and
CREATE
,
INSERT
,
DROP
, and
ALTER
privileges on
mysql.backup_history_new
are now required
only for backing up for the first time a MySQL Server that has
been upgraded from 5.7.22 or earlier and has been backed up by
MySQL Enterprise Backup before.
(Bug #27879530, Bug #28546256)
When the --show-progress=table
option was used, mysqlbackup gave a warning
in the error log on an aborted connection to the server near the
end of the operation. It was because the connection to the
server for writing to the backup_progress
table had remained open. With this fix, the connection is
properly closed after the mysqlbackup
operation is finished.
(Bug #27647283)
A restore operation for an incremental backup failed when individual tablespaces with relative file paths were involved. (Bug #26442994)
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)
Partial backups sometimes failed because full-text index files
had their file names matched by the regular expression provided
by the --include-tables
option, and
the files were then handled as ordinary tablespace files by
mysqlbackup. With this fix,
mysqlbackup excludes any full-text index
files from backups.
(Bug #25044900)
If, when a backup was in progress and mysqlbackup was reading the binary log (or the relay log) index file and the server tried to modify the index file (because, for example, a log flush or log purge just took place), the binary logging (or relay logging) stopped; the server also quit unexpected on Windows platforms. It was because mysqlbackup did not handle well the file sharing violation. With this fix, mysqlbackup now reads the index file using the local file system API, which handles the file sharing violation gracefully; also, mysqlbackup now copies the index file into its buffer and then closes it, instead of keeping it open for long, so the server can modify or delete the index file more easily. (Bug #22914974, Bug #26047119)