This section documents changes and bug fixes that have been applied in MySQL Enterprise Backup, version 3.6. This release has substantial enhancements to mysqlbackup syntax and processing over MySQL Enterprise Backup 3.5 and the older InnoDB Hot Backup product. For details, see Appendix B, Compatibility Information for MySQL Enterprise Backup.
Functionality Added or Changed
mysqlbackupcommand gains enhanced capabilities to do cold backups, with the
mysqlbackupcommand can now interface with Media Management Software (MMS) products such as Oracle Secure Backup, using the System Backup to Tape (SBT) protocol.
The backup operation now is much more “online” than in the past.
Several new options specify connection information and credentials for the database being backed up.
The connection-related options are made consistent with the corresponding options used for other MySQL client programs.
You no longer need to construct a dummy configuration file for use with MySQL Enterprise Backup. The
mysqlbackupcommand reads options from the standard MySQL configuration file, either from its own
[mysqlbackup]group or the generic
[client]group. Details about the layout and locations of files in the MySQL server are retrieved automatically using the database connection, so that you do not need to specify them in the configuration file.
For simplicity in managing and transferring backup data, you can produce a single-file backup as an alternative to a directory tree of backup files. The single-file backup is a foundational feature that is the basis for other important MySQL Enterprise Backup capabilities, such as streaming the backup data to another server and managing the backup data through a Media Management Software product such as Oracle Secure Backup.
metasubdirectory inside the backup data contains information about the backup itself. This metadata is known collectively as the manifest. You can use this information to build additional reporting or management features on top of MySQL Enterprise Backup.
You can associate comments with each set of backup data, either a single string specified on the command line, or through a separate text file.
For the fastest backup with the least disruption to MySQL server processing, options such as
--no-lockinglet you back up InnoDB tables exclusively. By skipping the backup of non-InnoDB files such as MyISAM tables and
.frmfiles, you can avoid the final phase of the backup that waits for other operations in the server to complete, then puts the server into a read-only state.
The mysqlbackup command could fail when the size of the
ibbackup_logfilefile in the backup directory exceeded 4GB. (Bug #12590463)
Fixed a potential syntax error in the
CHANGE MASTERstatement written to the
ibbackup_slave_infofile by the
--slave-infooption. (Bug #12540081)
When applying the log to a compressed backup, the operation could crash if the
--uncompressoption was omitted. Now, instead of the crash, an error message is displayed about the required option. (Bug #11780068)
Documented the maximum number of subdirectories (21) allowed in the
backup-dirpath. (Bug #11766768, Bug #59958)
If the MySQL server was running with the setting
SQL_MODE='TRADITIONAL', the mysqlbackup command could not create the
backup_historytable. This was a minor issue that did not halt the backup operation. (Bug #11766646, Bug #59800)
mysqlbackupcommand could crash during the apply-log stage when a database was dropped between a full backup and a subsequent incremental backup. (Bug #11766499, Bug #59623)
mysqlbackupcommand could fail on Windows systems if the path to the MySQL configuration file contained spaces. (Bug #11764927, Bug #57824)