Dear MySQL users,
MySQL Enterprise Backup v4.1.0, a new version of the online MySQL backup
tool, is now available for download from the My Oracle Support (MOS) website
as our latest GA release. This release will be available on eDelivery (OSDC)
after the next upload cycle. MySQL Enterprise Backup is a commercial
extension to the MySQL family of products.
MySQL Enterprise Backup 4.1.0 supports only the MySQL Server 5.7.9 and
above. For any earlier versions of the MySQL server, please use MySQL
Enterprise Backup 3.12 instead.
A brief summary of the changes in MySQL Enterprise Backup (MEB)
version 4.1.0 is given below.
Changes in MySQL Enterprise Backup 4.1.0 (2017-03-03)
Functionality Added or Changed
* MySQL Enterprise Backup now supports the --ssl-mode
option, which enables you to specify the security state
of the connection to the server. It replaces the client
side --ssl and --ssl-verify-server-cert options, which
are now deprecated. See the description of the --ssl-mode
option in MySQL 5.7 Reference Manual
(http://dev.mysql.com/doc/refman/5.7/en/) for details.
(Bug #23508228)
* A new option, --skip-final-rescan, makes mysqlbackup skip
the final rescan for InnoDB tables that are modified by
DDL operations after the database has been locked near
the end of a backup operation. This potentially shortens
the duration for the lock and reduces the backup's impact
on the server's normal operation. See the description for
--skip-final-rescan for details. (Bug #21094221)
* The output by mysqlbackup, which goes to the stderr
stream and the message log, has now been improved to
include the timestamps and thread IDs for all steps taken
by mysqlbackup, in order to provide more information for
debugging purposes. (Bug #20142619)
* During the final stage of a backup when MySQL Enterprise
Backup tried to temporarily put the database into a
read-only state using the FLUSH TABLES WITH READ LOCK
statement in order to copy non-InnoDB files, if a long
query was running on the server at the same time, the
FLUSH TABLES WITH READ LOCK statement could be taking too
long to finish, holding up further queries and eventually
bringing down the server.
A new mysqlbackup option --lock-wait-timeout can now be
used to specify the timeout in seconds for the FLUSH
TABLES WITH READ LOCK statement. If the timeout is
exceeded, the statement is failed and the lock on the
tables is released, so that queries held up by the lock
can then be executed. mysqlbackup then retries the
statement and continues with the backup. Default value
for --lock-wait-timeout is 60 [seconds]. (Bug #14339483)
* A full set of exit codes have now been implemented for
MySQL Enterprise Backup. Also, a new mysqlbackup command,
print-message, returns an exit message for any given exit
code supplied with the new option --error-code. See Exit
codes of MySQL Enterprise Backup
(http://dev.mysql.com/doc/mysql-enterprise-backup/4.1/en/
<http://dev.mysql.com/doc/mysql-enterprise-backup/4.1/en/meb-exitcodes.html>
meb-exitcodes.html
<http://dev.mysql.com/doc/mysql-enterprise-backup/4.1/en/meb-exitcodes.html>)
for details.
* To increase the performance for hot backups, mysqlbackup
now shortens the final phase of the backups by resizing
the MyISAM key cache before it locks the database with a
FLUSH TABLES WITH READ LOCK statement. The resize
triggers a flush of the MyISAM key cache, which reduces
the time it takes to run the FLUSH TABLES WITH READ LOCK
statement. The MyISAM key cache size is changed back to
its original value afterward.
* Apply-log operations can now be performed with multiple
worker threads in parallel, which can improve performance
for the operations. The number of threads to be used can
be specified with the --process-thread option.
* The copying of redo log files into backups has been made
faster, shortening the overall backup time in some cases
and making it less likely that a backup fails because a
redo log file has been overwritten before it is copied.
* MySQL Enterprise Backup now supports optimistic
incremental backup, in which mysqlbackup scans only those
InnoDB data files that have been modified since the last
backup for changed pages and then saves them into the
incremental backup. It potentially makes incremental
backups faster, and is performed by specifying
--incremental=optimistic. See Full-scan versus Optimistic
Incremental Backup
(http://dev.mysql.com/doc/mysql-enterprise-backup/4.1/
<https://dev.mysql.com/doc/mysql-enterprise-backup/4.0/en/mysqlbackup.incremental.html#mysqlbackup.optimistic.incremental>
en/mysqlbackup.incremental.html#mysqlbackup.optimis
<https://dev.mysql.com/doc/mysql-enterprise-backup/4.0/en/mysqlbackup.incremental.html#mysqlbackup.optimistic.incremental>
tic.incremental
<https://dev.mysql.com/doc/mysql-enterprise-backup/4.0/en/mysqlbackup.incremental.html#mysqlbackup.optimistic.incremental>)
for details.
* In order to minimize the impact of a hot backup on the
MySQL server, the copying of the buffer pool dump files
and some of the metadata files is now performed before
the final phase of the backup in which the server
instance is locked. This shortens the duration for the
lock and reduces the backup's impact on the server's
normal operation.
Also, to minimize the resource used on a backup, the
copying of the buffer pool dump files is no longer
performed for partial and offline backups, for which the
buffer pool dump is usually not very useful.
Bugs Fixed
* The Release number for the RPM packages of MySQL
Enterprise Backup always said "1," instead of giving the
release number of the Linux distribution for which the
package was built. (Bug #25538798)
* An apply-log or apply-incremental-backup operation failed
when, during the time the backup was created, any tables
have been dropped and then recreated with the same name
for more than once. (Bug #25334929)
* When creating a full image backup with the --no-locking
option, mysqlbackup failed to write the binary log
information to the backup history table and the
backup_variables.txt file. The result was that when
creating an incremental image backup based on the full
backup, the attempt to copy the binary log files from the
server into the incremental image backup (which is the
default behavior) would fail, causing the incremental
backup to stop. With this fix, the binary log information
is no longer missing after the full backup, so the
incremental image backup no longer fails." (Bug
#25296324)
References: See also: Bug #19915713.
* A backup became corrupted if, during the backup process,
a DDL operation that took advantage of MySQL server's
online DDL feature
(http://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl
<http://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl.html>
.html <http://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl.html>)
occurred. This was because mysqlbackup did not
support the server feature---and it still does not. This
fix avoids the error by having mysqlbackup turn the
server's system variable old_alter_table to "1" at the
beginning of a backup if it is "0," so that any DDL
operations that take place during the backup are handled
with the old table copy method. mysqlbackup then turns
the variable back to "0" near the end of the backup
operation.
Notice that in cases where mysqlbackup quits unexpectedly
and does not turn old_alter_table back to its original
value, the user will have to turn the value back to "0"
manually on the server, in order to return the server to
its original configuration. This should be performed if
the statement "Server system variable 'old_alter_table'
was set to '0'. Setting it to '1'" appears in the early
output of mysqlbackup, but the statement "Setting server
system variable 'old_alter_table' back to '0'" does not
appear before mysqlbackup quits. (Bug #25217215)
* A backup operation sometimes failed due to corruption of
the copied redo log, and the corruption occurred because
checksum validation for redo logs was not activated for
mysqlbackup. This fix restores the checksum function, so
that the validation is performed when
innodb_log_checksums=ON on the backed up server. When a
chuck of redo log data fails the validation, mysqlbackup
tries to reread the data from the server.
However, redo log checksum validation is not performed
for offline backups, and online backups fail when the
value of innodb_log_checksums is switched off on the
server when the backup is in progress. (Bug #25057394)
* In some cases (for example,when the backup could not be
validated, or when the backup directory could not be
created), mysqlbackup threw an error when an operation
failed without creating a message log file. With this
fix, a message log file is created in those cases. (Bug
#24678204)
* mysqlbackup logged double entries with wrong information
into the backup_history table for optimistic backups.
(Bug #24502876)
* Backups for a slave server in a multi-source replication
setup using the --slave-info option failed. (Bug
#24444950)
References: See also: Bug #21830316.
* If a backed up server was configured with
innodb_undo_tablespaces being non-zero, during a backup,
mysqlbackup emitted meaningless warning messages about
the tablespaces already existing in the cache. This fix
removes those messages. (Bug #24400230)
* During an apply-log or a copy-back-and-apply-log
operation on a backup with encrypted InnoDB tables, if no
value was specified for the --encrypt-password option
used, the operation failed with the complaint that no
encryption password was specified. With this fix,
mysqlbackup asks the user for the encryption password
when it is in the same situation. (Bug #24364442)
* An apply-log operation failed for a backup of a server
that contained tablespaces outside of its data directory.
It was because those tablespaces, unlike tablespsaces in
the data directory, were not loaded by mysqlbackup before
the apply-log operation started. This fix ensures all
tablespaces are loaded. (Bug #22026145)
* When running the backup-and-apply-log command without a
connection to the MySQL server, mysqlbackup could not
know the correct binary log file name and binary log
position for the backup; yet, at the end of the
backup-and-apply-log operation, mysqlbackup still printed
out some values for the binary log file name and
position, which were random in nature. (Bug #21623089)
Thanks,
On behalf MySQL RE team at Oracle
-Sreedhar S
