D.2. Changes in MySQL Enterprise Backup 3.7.0 (2012-01-04)

This section documents changes and bug fixes that have been applied in MySQL Enterprise Backup, from version 3.5.1 through version 3.7.0.

Functionality Added or Changed

When managing backup data using the SBT interface of products such as Oracle Secure Backup, you can change certain settings in the media management software by setting environment variables that are recognized by the SBT library. The new --sbt-environment option of the mysqlbackup command lets you set such environment variables for the duration of the backup job only, rather than using a wrapper script to set and unset the variables.
Although the intended purpose of the --sbt-environment option is to pass environment variables used by the SBT library, you can set any Unix, Linux, or Windows environment setting this way for the duration of the backup job.
The single-file backup feature now includes checksum verification to ensure the backup data remains unchanged during any transfers to other systems. Each file within the backup image is tested against a checksum calculated using the CRC32 algorithm, either when files are extracted from the backup image, or using the new mysqlbackup option validate to test a backup image without extracting. For example:
```
      mysqlbackup other_options --backup-image=image_file validate
```
A new option for the mysqlbackup, --only-innodb-with-frm, lets you back up InnoDB tables and their associated .frm files with minimal disruption to database processing.
By default, all InnoDB and non-InnoDB tables are backed up, along with all the .frm files. While the .frm files are being copied, the instance is put into a read-only state. With the --only-innodb option introduced in MySQL Enterprise Backup 3.6, only InnoDB tables are backed up, but you must copy the .frm files manually, and again this stage happens with the instance in a read-only state. The --only-innodb-with-frm is intended for backups where you can ensure that no ALTER TABLE, CREATE TABLE, DROP TABLE, or other DDL statements modify the .frm files for InnoDB tables during the backup operation. If the mysqlbackup detects that any of the relevant .frm files was modified or deleted during the backup job, the command halts with an error.
The mysqlbackup option --start-lsn is now optional for incremental backups. If you specify the location of an existing full or incremental backup with the new --incremental-base option, you can omit the --start-lsn option and the mysqlbackup command automatically determines the appropriate LSN.
For safety, the backup job halts with an error if the LSN information cannot be retrieved, or if there is a mismatch between the LSN recorded in the previous backup and the LSN reported by the MySQL instance.
The automatic LSN detection works with both the original (--incremental) and new (--incremental-with-redo-log-only) incremental backup techniques.
The mysqlbackup now offers an alternative method of performing incremental backup for InnoDB tables. This technique involves copying the redo log. This backup method is an alternative to the incremental backup of InnoDB tables.
To enable the redo-log-only incremental backup method, specify the --incremental-with-redo-log-only option on the mysqlbackup command line, instead of the --incremental option).

Note

The benefit of this option is a reduction in random I/O during the backup stage, in favor of sequential I/O. The older incremental backup technique reads only changed blocks from the InnoDB data files. If a high proportion of blocks changed, I/O overhead to read the changed data could limit the performance benefits of an incremental backup. The new technique minimizes this I/O overhead by doing sequential reads to copy the relatively small ib_logfile*files. The new technique tends to perform better on systems with big InnoDB tables that receive frequent updates, broadly distributed within the tables. If you have small tables, or relatively few changes, or changes over and over again to the same pages on disk, the old technique might perform better for you. The backup information from the redo logs might also take longer to apply during the apply-log phase. Run benchmarks to determine the best technique for your workload.
This technique relies on you having sufficient redo log data to cover the period since the last incremental backup. Because the InnoDB redo log uses a circular buffer where older entries eventually are overwritten, make incremental backups frequently to avoid having older changes unavailable for the incremental backup. Ensure that the value of the innodb_log_file_size configuration option is large enough to hold all the changes to InnoDB data that accumulate between incremental backups.
When you apply the log data from a series incremental backups to a full backup, the incremental backup data can be produced using either of the techniques. Some incremental backups could be produced by the --incremental option and others with the --incremental-with-redo-log-only option.
Because the incremental backup data format produced by the --incremental-with-redo-log-only option is different from the format of MySQL Enterprise Backup 3.6 or 3.5, older mysqlbackup versions cannot perform the apply step on a redo-log-only backup. If you use the new incremental backup technique, upgrade the mysqlbackup command to the latest MySQL Enterprise Backup level on any machines where you run the apply-log step.
This feature is not available in the ibbackup command, which is intended only for compatibility with the option syntax from MySQL Enterprise Backup 3.5 and the earlier InnoDB Hot Backup product.
Performance work within the mysqlbackup command makes backup jobs faster with less overhead.
Performance of backup-related I/O operations is improved, particularly on Windows, by reusing I/O library code and best practices from the MySQL Server product.
CPU overhead is lessened by reducing the number of memory allocation and deallocation operations.

Bugs Fixed

The backup and some combinations of extract and --src-entry options could fail depending on the existence or non-existence of target directories. In most cases, the error was due to a directory not existing and mysqlbackup failing to create it. An extract option with no --src-entry option could fail if the target directory did already exist. (Bug #13465782)
When using mysqlbackup with the copy-back option, specifying a --datadir option with a trailing slash on the directory name could fail with an uninformative error message. This issue only occurred on Windows systems. (Bug #13392053)
MySQL Enterprise Backup now does stricter checking of LSN values to prevent the apply step for incremental backups to be carried out in an incorrect order. Now mysqlbackup gives an error if asked to apply an incremental backup that is older than the full backup, or if another incremental backup needs to be applied first. (Bug #13350012)
A backup operation could fail if the database being backed up contained only views and no tables. (Bug #13359833)
Attempting to re-run an apply-log operation a second time would fail, when using the --force option to overwrite files. (Bug #13012586)
A missing datadir option in the MySQL configuration file could cause the mysqlbackup command to halt. (Bug #12838474)
During a backup using the --only-innodb option, an incorrect message was displayed regarding a time interval to copy non-InnoDB files. (Bug #12691358)
Fixed a potential syntax error in the CHANGE MASTER statement written to the ibbackup_slave_info file by the --slave-info option. (Bug #12540081)
The apply-log and copy-back options now print messages showing the times for the start and end of those operations. (Bug #12313355, Bug #12837622)
Clarified processing of duplicate options. When the same option is specified more than once, the last one takes precedence. This is standard MySQL practice, not an error or warning situation. (Bug #11763378, Bug #56076)

Previous / Next / Up / Table of Contents

User Comments

Add your own comment.

Top / Previous / Next / Up / Table of Contents