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:
With the
Windows Native
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
--password option.
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.
Bugs Fixed
Under some circumstances, the mysqlbackup
with the --no-locking option halted with the
message Backup of non-innodb tables failed.
Now, the --no-locking option prevents this
issue.
(Bug #12952150)
Under MySQL 5.5.8 and higher, a full backup using the
mysqlbackup command could fail with the
combination of settings binlog_format=ROW and
transaction-isolation=READ-COMMITTED. The
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
example, coppy-back), caused
mysqlbackup to halt. Now, incorrect options
produce a descriptive error message rather than an assertion
failure.
(Bug #12780833)
The mysqlbackup options
copy-back, apply-log, and
apply-incremental-backup did not print the
success message “mysqlbackup completed OK!”, even
when the operation was successful.
(Bug #12710941)
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 --only-innodb option.
In MySQL Enterprise Backup 3.5, when applying an incremental
backup, .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
delete .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
dropped, its .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.
(Bug #12636719)
The backup-to-image option to produce a
single-file backup left behind zero-byte temporary files
ibdata1 and
mysql/ibbackup_binlog_marker.ibd after
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.
(Bug #12408255)

User Comments
Add your own comment.