Functionality Added or Changed
MySQL Enterprise Backup can now authenticate to the server being backed up using the Enterprise authentication plugins available in the commercial distributions for MySQL 5.5.16 and higher. For example:
authentication plugin, you can set up a MySQL user ID
named the same as the Windows user ID, grant MySQL
privileges as described in
Section 3.1.2, “Grant MySQL Privileges to Backup Administrator”, and then perform
backups from that Windows account by specifying the
--user option without a
With the PAM authentication plugin, you can connect to the MySQL server using a flexible system to map user IDs and associated privileges.
For more details about the MySQL pluggable authentication feature, see Pluggable Authentication.
Under some circumstances, the mysqlbackup
--no-locking option halted with the
Backup of non-innodb tables failed.
--no-locking option prevents this
Under MySQL 5.5.8 and higher, a full backup using the
mysqlbackup command could fail with the
combination of settings
error message was:
mysqlbackup: ERROR: Could not lock tables. Aborting. mysqlbackup: ERROR: Backup of non-innodb tables failed.!
(Bug #12922167, Bug #62268)
Specifying mysqlbackup options incorrectly
could cause a fatal error. For example, using an underscore
apply_log) instead of a dash
apply-log), or misspelling an option (for
mysqlbackup to halt. Now, incorrect options
produce a descriptive error message rather than an assertion
The mysqlbackup options
apply-incremental-backup did not print the
success message “mysqlbackup completed OK!”, even
when the operation was successful.
This fix changes the way non-InnoDB files are handled when
applying an incremental backup to a full backup. The behavior
differs depending on whether or not the incremental backup was
taken with the
In MySQL Enterprise Backup 3.5, when applying an incremental
.frm files were deleted from the full
backup, if they were not present in the incremental backup. In
MySQL Enterprise Backup 3.6.0, this behavior changed, so that
applying an incremental backup to a full backup would never
.frm and other non-InnoDB files. This
change made it more convenient to take a full backup, followed
by incremental backups of InnoDB tables using the
--only-innodb option. But if a table was
.frm file would not be removed
when subsequent incremental backups were taken and applied to
the full backup. The table would be reported by the
SHOW TABLES statement, but would
give an error when accessed by SQL statements.
With this bug fix, an incremental backup using default options
reverts to the original behavior, synchronizing the
.frm files with the full backup, including
deleting them when appropriate. Incremental backups with the
--only-innodb option retain the cautious
behavior that never deletes
.frm and other
non-InnoDB files when applied to full backups. If you use
--only-innodb with incremental backups, you
must handle the deletion of non-InnoDB files yourself in the
full backup directory.
backup-to-image option to produce a
single-file backup left behind zero-byte temporary files
completing. These files were left behind in the work directory
specified by the
--backup-dir option, and in
the image file. Now these files are removed as intended.