Documentation Home
MySQL Enterprise Backup 3.7 User's Guide
Download this Manual
PDF (US Ltr) - 0.8Mb
PDF (A4) - 0.8Mb

MySQL Enterprise Backup 3.7 User's Guide  /  ...  /  Changes in MySQL Enterprise Backup 3.6.1 (2011-09-28)

D.3 Changes in MySQL Enterprise Backup 3.6.1 (2011-09-28)

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:

    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, copy-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
Sign Up Login You must be logged in to post a comment.