MySQL Enterprise Backup 3.12 Release Notes
If the value for the
innodb_checksum_algorithm
or
backup_innodb_checksum_algorithm
option provided on the mysqlbackup command
line differed from that of the server,
mysqlbackup gave a single warning that the
checksum algorithm specified might be incompatible with the
server. Starting with 3.12.2, to be consistent with the way
checksums are handled by the MySQL server since 5.6.25,
mysqlbackup gives a separate warning for
every single page of data in every .ibd
file for which the checksum algorithm specified does not match
the one used on the server.
(Bug #22509993)
Values for MASTER_USER
and
MASTER_PORT
are now included in the
CHANGE MASTER TO
statement in the slave
information file (meta/ibbackup_slave_info
)
when the --slave-info
option is used
for backing up a slave server.
(Bug #14213115)
When mysqlbackup came across a file of an unknown file type and its path name contained characters that mysqlbackup could not convert to the file system character set, it threw an error. With this fix, mysqlbackup continues with its operation in the situation after giving a warning. (Bug #22098742)
A backup failed if, towards the end of the backup process, mysqlbackup found the binary log file that was current at the beginning of the backup had been purged. With this fix, mysqlbackup now ignores the fact that the file has been purged, resets the log position to the now current binary log file, and continues with the backup without raising any issues. (Bug #21655145)
During a backup, mysqlbackup performed, by
default, an SQL query to get storage engine information that was
to be put into the backup_history
table.
Because the query caused all table files on the server to be
scanned, it consumed a great amount of IO resources when there
were many tables on the server, resulting sometimes in serious
performance issues. With this fix, only tables included in the
backup are scanned, thus reducing the IO stress on the server.
(Bug #21098174)
When creating a compressed backup, mysqlbackup threw an error if a table on the server was dropped in the middle of the process. With this fix, the dropped table is ignored (as it does not need to be restored) and mysqlbackup finishes without throwing an error. (Bug #21087079)
References: See also: Bug #18358912.
When a backup took a long time to perform and the binary logs were rotated in the middle of the process, mysqlbackup lost track of the binary log files it was copying, skipping the second last log file and attempting to copy the last one twice; that resulted in a file creation error, at which point mysqlbackup exited without releasing its lock on the tables in the database. With this fix, all binary log files are now copied properly, and the lock on the tables is released at the end of the backup process as usual. (Bug #20971763)
When restoring an incremental backup image, if the binary log in the backup was larger than 16MB, the restored binary log would become corrupted, as mysqlbackup kept overwriting the same 16-MB file again and again with binary log contents. With this fix, the binary log is now correctly restored and has the same size as it did on the backed-up server. (Bug #20915642)
A backup of a slave server failed if, during the backup, a relay log file got purged from the slave server (for example, due to a log file rotation). With this fix, backup continues even if mysqlbackup finds a relay log file missing. (Bug #20769891, Bug #76312, Bug #21655314, Bug #19255925)
When the --password
option was used
without an argument with the
copy-back-and-apply-log
command,
mysqlbackup did not prompt user for a
password, but either took the password from the defaults files,
or took it to be an empty string when no value was specified in
the defaults files.
(Bug #20657939)
When the trace
level of
mysqlbackup messages was greater than
“0,” if the operation command for
mysqlbackup was invalid or missing, a stack
trace and some error messages were printed, which made it look
like mysqlbackup had crashed. With this fix,
a new message is now shown before the stack trace, to better
explain the situation.
(Bug #20281022)
If an incremental backup had already been applied to a directory
backup with the
apply-incremental-backup
command and
the up-to-date backup was then restored to a data directory, it
was possible to restore the same incremental backup again to the
data directory using the
copy-back-and-apply-log
command,
potentially causing data inconsistencies. With this fix, the
incremental data can be reapplied only when the
--force
option is used. Without the
--force
option, the
copy-back-and-apply-log
command
skips the apply log operation if the incremental backup is a
directory backup and throws an error if it is an image backup.
(Bug #18004179)