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)