This section documents changes and bug fixes that have been applied in MySQL Enterprise Backup, from version 3.5.1 through version 3.8.1. The 3.8.1 release contains mainly fixes and enhancements compatibility with features of MySQL 5.6.
Functionality Added or Changed
In MySQL 5.6, you can change the physical layout of the InnoDB
system tablespace
through the configuration options
innodb_undo_directory,
innodb_undo_tablespaces, and
innodb_undo_logs (formerly
innodb_rollback_segments).
These options move the InnoDB undo
log into one or more separate files, possibly outside the
MySQL data directory or even on a different storage device.
These files are named with sequential numbers:
undo001, undo002,
undo003, and so on, up to the number
specified by innodb_undo_tablespaces.
The mysqlbackup command recognizes these
options during a backup, and retrieves the associated files from
the specified location. When the mysqlbackup
command creates a backup, it always stores these undo data files
in the same directory as the other
data files making up the
system tablespace. During a restore operation, the files are
copied to the appropriate location, depending on the setting for
innodb_undo_directory on the
server where restore takes place.
(Bug #16168947)
New server options present in MySQL 5.6 are accepted on the mysqlbackup command line when a database connection is not available, and are stored along with other instance-wide settings in the backup metadata:
(Bug #16033618, Bug #15951510)
Backups can be taken while
online DDL operations are
in progress on InnoDB tables. See
Online DDL for InnoDB Tables for details about this MySQL
5.6 feature.
(Bug #15932180)
MySQL Enterprise Backup can now handle InnoDB tables backed up
to non-standard locations using the DATA
DIRECTORY clause of the MySQL 5.6
CREATE TABLE statement. For each
table created outside the database subdirectory, a
.isl file in the database
subdirectory contains the absolute pathname of the associated
.ibd file, acting like a
symbolic link to the actual tablespace file.
The mysqlbackup command reads the
.isl files to locate the associated
.ibd files during a backup. It stores the
.isl files in the backup directory using the
extension .bl. If the server where you
restore the backup does not have the same directory structure as
the backup server, and you need to put the restored
.ibd files in some different location, edit
the .bl files before doing the restore.
(Bug #15932375)
MySQL 5.6 includes the
innodb_page_size configuration
option to set a page size
other than the traditional 16KB default. The page size is set
permanently when the instance is created, and cannot be changed
afterward.
The mysqlbackup command can back up MySQL
instances that use any of the new page sizes (8KB, 4KB, 2KB, or
1KB). When restoring, set
innodb_page_size to the same
value as on the server that was backed up; otherwise, the
restore operation halts with an error.
(Bug #14761559, Bug #16070834)
MySQL Enterprise Backup supports the GTID feature of MySQL 5.6:
The GTID feature is compatible with the CSV tables that the mysqlbackup command uses to log job progress and history.
When a server using the GTID feature is backed up,
mysqlbackup produces a file
gtid_executed.sql as part of the backup
data. This file contains a SQL statement that sets the
GTID_PURGED configuration option. Execute
this file using the mysql command line
after restoring the backup data on a slave server.
Optionally, you can uncomment the CHANGE
MASTER command in this file and add any needed
authentication parameters to it, before running it through
mysql.
For servers not using GTIDs, you can use the
--slave-info option as before,
then edit and execute the
ibbackup_slave_info file afterward.
For more information about using MySQL Enterprise Backup with replication, see Chapter 6, Using MySQL Enterprise Backup with Replication. (Bug #14767426, Bug #14797808, Bug #14722659)
Normally, the InnoDB system tablespace is extended by one or more megabytes at a time. Under some circumstances, particularly in a disk-full or almost-full situation, MySQL can extend the InnoDB system tablespace by some amount less than a megabyte, and this trailing portion is unused. Now the mysqlbackup command backs up such oddly sized system tablespaces even though the size does not precisely match the specified size. This condition causes a warning rather than an error. The unused fractional megabyte is removed from the backup data. (This particular file-size feature applies only to the system tablespace, not to the file-per-table tablespaces in the .ibd files.)
The mysqlbackup command now supports the UNC (Universal or Uniform Naming Convention) syntax for specifying locations on shared disks. This feature lets you start backups to shared drives using Windows Task Scheduler, when shared drives cannot be mapped to a drive letter.
The UNC syntax for Windows systems has the generic form:
\\ComputerName\SharedFolder\Resource
You can use either forward or backward slashes in the path names.
The mysqlbackup command does not support the "long UNC" syntax:
\\?\UNC\ComputerName\SharedFolder\Resource
The UNC path names can be specified with any backup command and option.
Do not use UNC paths to specify the location of InnoDB data files and log files to be backed up. Such files cannot be reliably backed up over a network file system. MySQL Enterprise Backup does not issue any warning in this case.
Bugs Fixed
Important Change:
When backing up a slave server using the
--slave-info option, updates could
be lost when restoring the backup and starting replication using
the command in the meta/ibbackup_slave_info
file. This issue could arise if the replication SQL thread was
not in synch with the replication I/O thread.
Prior to this fix, the workaround for backups with the
--slave-info option was to stop the I/O
thread and wait for the SQL thread to catch up before starting
the backup.
(Bug #13588571, Bug #15865869)
An apply-log operation could fail if the server used an
innodb_page_size setting
different from the default of 16KB.
(Bug #16084912)
The --suspend-at-end and
--exec-when-locked options did not
work properly in MySQL Enterprise Backup 3.8. The suspension
code has been rewritten to work in conjunction with the
multithreaded system of readers and writers.
(Bug #16078126, Bug #16168131)
MySQL Enterprise Backup 3.8.1 now supports the different
checksum settings of the
innodb_checksum_algorithm
configuration option in MySQL 5.6.
Prior to MySQL Enterprise Backup 3.8.1, when the value of the
innodb_checksum_algorithm was
strict_crc32 or
strict_none, the server could not be started
after a sequence of backup, apply-log, and restore operations.
Checksums were created in the InnoDB
data files during the
apply-log phase that were incompatible with the checksum
algorithms required in the server.
With this fix in place, there are still some restrictions
regarding the settings for the
innodb_checksum_algorithm
during backup and restore:
A server backed up while the
strict_crc32,
strict_innodb, or
strict_none setting is in effect for
innodb_checksum_algorithm
must be restored to a server with that same
innodb_checksum_algorithm setting.
If a server contains data produced under different
innodb_checksum_algorithm
settings, because the option setting was changed during the
lifetime of the server, that data cannot be restored to a
server with one of the strict_* options
for innodb_checksum_algorithm.
(Bug #15951510)
When a slave server was
backed up with the --slave-info
option, the meta file backup_content.xml
contained incorrect data in the section underneath the
<binlog_file> tag.
(Bug #15926218)
The mysqlbackup command could encounter a
severe error during the apply-log
step, or the corresponding phase of
apply-incremental-backup, if DML or
DDL had been done during the backup. (The apply log algorithm
rounded the size of data files to the next lower 1MB border, if
the size was not an exact number of megabytes. The apply log
algorithm also did not ignore temporary data files and failed
when it detected duplicate tablespace IDs.)
(Bug #15841875, Bug #14704347, Bug #15932180)
A backup operation could fail with a serious error (segmentation
fault) if the --connect-if-online
option was specified and the MySQL server was not online.
(Bug #14788375)
There are 2 database connections used by the
mysqlbackup command. The first connection is
used for reading server configuration, and locking and updating
the history table. The second connection is used for reading
incremental base details during incremental backup. The second
connection did not specify an
autocommit setting, possibly
causing a stall when the server had the setting
autocommit=0. Now
mysqlbackup specifies
autocommit=1 automatically in
this connection.
(Bug #14637052)
If the .ibd file for an
InnoDB table created under the
innodb_file_per_table option
was renamed or removed while a backup was in progress, the
mysqlbackup command could fail. This issue
primarily affected tables with a size greater than 60 MB that
were dropped or renamed during the backup operation.
(Bug #14590007)
The password specified by the --password
option was printed in mysqlbackup command
output, rather than being masked. This issue affected the
mysqlbackup command, but any password
parameters recorded in the backup_history
table were masked correctly.
(Bug #14576054)
This fix addresses problems doing a single-file backup (using
the --backup-image option) when the
innodb_data_file_path or
innodb_data_home_dir configuration options
contained absolute paths. This issue typically affected
configurations with InnoDB files split across
multiple storage devices. The symptoms and associated fixes are:
The backup operation failed if InnoDB
data files were placed in a subdirectory of
datadir. Now
mysqlbackup creates all required
subdirectories in the backup_dir directory.
The backup operation failed if InnoDB
data files were placed in a sub-subdirectory of
datadir. It refused to work
if any directory was found in the database directories. The
error is now a warning instead.
InnoDB data files were copied twice, if
they were in a subdirectory of
datadir: once during the
phase the copies InnoDB files and again
in the phase that copies non-InnoDB
files. During this second phase, all files in the database
directories are copied, which mistakenly included the
InnoDB files from subdirectories of
datadir. Now
mysqlbackup compares each filename from
the datadir subdirectories
against each InnoDB data file name from
the system tablespace, to avoid copying the files a second
time. .ibd files were
not affected by this issue, as they are recognized by their
file name extension.
MEB can now back up
system
tablespace data files inside the source
datadir if
backup_innodb_data_home_dir and
backup_innodb_data_file_path were
configured accordingly. Fixed by checking each backup target
system tablespace data file against the server's
datadir.
(Bug #14499912)
The default for the option
--only-innodb-with-frm was
mistakenly set to all when it was intended to
be related. The default for that option is
now related.
(Bug #14507779)
On a busy server with a high write workload, the mysqlbackup command could fail with an error such as:
mysqlbackup: ERROR: Page at offset 0numberin /path/db_name#table_name.ibd seems corrupt!
The problem was due to a race condition where a
checksum was written just
as the page was being backed
up, before the corresponding data was stored on the page. Now
mysqlbackup waits and re-tries the read
operation when a checksum mismatch occurs. The new
mysqlbackup options
--page-reread-time and
--page-reread-count let you adjust
the mechanism for re-trying page reads. If you continue to
encounter such errors, re-try the backup with higher values for
these options to reduce the possibility of encountering the race
condition.
(Bug #14489495)
A configuration file with --ssl-* options in
the [client] section caused the
mysqlbackup command to fail, rather than
being ignored as with most other unused options. A workaround
was to copy the configuration file, remove the
--ssl-* parameters, and run
mysqlbackup with the
--defaults-file option to use the smaller
configuration file.
The fix causes mysqlback to recognize and
handle all the SSL options currently recognized by the server:
--ssl, --ssl-key,
--ssl-cert, --ssl-ca,
--ssl-capath,
--ssl-cipher, and
--ssl-verify-server-cert.
(Bug #13520946)
The --slave-info option is not
compatible with
--only-innodb-with-frm,
--only-innodb-with-frm=all, or
--only-innodb-with-frm=related. Now
the mysqlbackup command reports a
command-line error if you specify those options in combination.
(Bug #13414742, Bug #63355)
If the MySQL server had a low value for the
wait_timeout configuration
option, large backups (particularly for large
MyISAM tables) could fail due to timeout
errors. The timeout could also prevent the
mysql.backup_progress table from recording
the final details of the failed backup. The fix raises the value
of wait_timeout to the maximum
value within the session opened by the
mysqlbackup command. The maximum timeout
value is platform-specific: approximately 24 days on Windows
systems, and 1 year for other platforms.
(Bug #13258784, Bug #13416025, Bug #14468879)