Mysql enterprise backup 4.1 download

MySQL Enterprise Backup 4.1 only supports MySQL 5.7. For MySQL 5.6 and earlier, use MySQL Enterprise Backup 3.12.

For MySQL 5.7.11 and earlier, backup for InnoDB tablespaces encrypted with “MySQL Enterprise Transparent Data Encryption (TDE)” is not supported by MySQL Enterprise Backup 4.1. See the discussion here for details.

MySQL Enterprise Backup is a backup utility for MySQL servers. It is a multi-platform, high-performance tool, offering rich features like “hot” (online) backup, incremental and differential backup, selective backup and restore, support for direct cloud storage backup, backup encryption and compression, and many other valuable features.

While optimized for use with InnoDB tables, MySQL Enterprise Backup is capable of backing up and restoring all kinds of tables created by any kinds of storage engines supported by MySQL. The parallelism of its read and write processes (performed in independent, multiple threads) and its block-level parallelism (different threads can read, process, or write different chunks within a single file) allow backup and restore processes to be completed with great speed, and often with a significant performance gain when compared to a logical backup using tools like mysqldump.

MySQL Enterprise Backup is a valuable tool for maintaining and safeguarding your MySQL data, and for quick and reliable recovery when accidents or disasters strike. It is part of the MySQL Enterprise Edition, available to subscribers under a commercial license.

Among other things, this manual explains:

• How to install MySQL Enterprise Backup.

• The different kinds of backups that can be performed with MySQL Enterprise Backup, how to perform them, and some tips on choosing the right kind of backups for your system.

• How to restore backups created by MySQL Enterprise Backup.

• How to use MySQL Enterprise Backup in special situations or for special purposes (for example, setting up replication, using Media Management Software (MMS) products, or using a Distributed File System (DFS)).

• The mysqlbackup client, its commands and command options.

• MySQL Enterprise Backup 4.1 failed to backup a MySQL Server that has been backed up by MySQL Enterprise Backup 4.0 before. It was due to the way the backup_history table was queried, which has now been fixed. (Bug #29208386)

• When working with a Group Replication cluster, mysqlbackup might quit unexpectedly near the end of a backup operation when, in order to write to the backup_history table, it tried to connect with an unencrypted connection to one of the nodes on which the backup user had not logged on before. It happened when the backup user was created with the caching_sha2_password plugin plugin, so that it must log on with an encrypted connection when it connected to the server for the first time; the attempt to log on thus failed, and mysqlbackup could not handle the failure. With this fix, at such failures, mysqlbackup quits gracefully with the warning that the backup operation is finished without updates to the backup history. (Bug #28893180)

• Restoring an incremental backup image using the copy-back-and-apply-log command failed with mysqlbackup complaining that the server repository configuration (including, for example, value of innodb_data_file_path) was unknown for the target server, unless the configuration is explicitly supplied to mysqlbackup. With this fix, mysqlbackup gets the required information from the backup-my.cnf file already restored with the base backup of the incremental backup. (Bug #28411028)

• A restore operation could corrupt a backup when, by mistake, a user specified the source directory to become the target directory for restoring some files (for example, specifying what was the backup's --backup_innodb_data_home_dir value as the restore's --innodb_data_home_dir value). This fix prevents the problem by having mysqlbackup throw an error when the command options make the source and target file paths the same for any file copying during a restore. (Bug #28376873)

• On FreeBSD platforms, using the --show-progress option did not make mysqlbackup print progress reports. (Bug #28350122)

• After encrypted InnoDB tables have been restored, sometimes the restored server could not be started, or the encrypted InnoDB tables could not be opened after the server had been started.

  This fix not only resolves the aforementioned issues, but also two other problems: the failure to restore a backup containing encrypted InnoDB tables that were row-compressed, and the failure to complete a backup when an encrypted InnoDB table was created in the middle of the backup operation. (Bug #28301281)

  References: See also: Bug #28360241, Bug #27168458.

• While MySQL Server interprets the system variable setting --innodb_checksum_algorithm=0 to mean --innodb_checksum_algorithm=crc32, a mysqlbackup operation (except for backup) failed when --innodb_checksum_algorithm=0 was set as a configuration option on the backed up server. With this fix, mysqlbackup now takes --innodb_checksum_algorithm=0 as valid and interprets it as --innodb_checksum_algorithm=crc32. (Bug #28295519)

• The Windows version of MySQL Enterprise Backup did not display its build ID when invoked. (Bug #27916702)

• mysqlbackup quit unexpectedly when backing up a MySQL Server of release 4.1.2 or later for the first time if the ALTER privilege on the mysql.backup_history_new table had not been granted to the MySQL user with which mysqlbackup connected to the server. With this fix, mysqlbackup quits gracefully in the situation after throwing the proper error.

  Also, the CREATE, INSERT, and DROP privileges on mysql.backup_history_old and CREATE, INSERT, DROP, and ALTER privileges on mysql.backup_history_new are now required only for backing up for the first time a MySQL Server that has been upgraded from 5.7.22 or earlier and has been backed up by MySQL Enterprise Backup before. (Bug #27879530, Bug #28546256)

• When the --show-progress=table option was used, mysqlbackup gave a warning in the error log on an aborted connection to the server near the end of the operation. It was because the connection to the server for writing to the backup_progress table had remained open. With this fix, the connection is properly closed after the mysqlbackup operation is finished. (Bug #27647283)

• A restore operation for an incremental backup failed when individual tablespaces with relative file paths were involved. (Bug #26442994)

• When the option --only-innodb-with-frm or --no-locking was used during a backup operation, the backup sometimes failed with mysqlbackup complaining that the highest LSN was larger in a copied page than on the backed-up server. It was because mysqlbackup did not perform a log flushing before copying the redo log when either of the mentioned options was used. With this fix, log flushing was always performed to prevent the error. (Bug #25412655)

• Partial backups sometimes failed because full-text index files had their file names matched by the regular expression provided by the --include-tables option, and the files were then handled as ordinary tablespace files by mysqlbackup. With this fix, mysqlbackup excludes any full-text index files from backups. (Bug #25044900)

• If, when a backup was in progress and mysqlbackup was reading the binary log (or the relay log) index file and the server tried to modify the index file (because, for example, a log flush or log purge just took place), the binary logging (or relay logging) stopped; the server also quit unexpected on Windows platforms. It was because mysqlbackup did not handle well the file sharing violation. With this fix, mysqlbackup now reads the index file using the local file system API, which handles the file sharing violation gracefully; also, mysqlbackup now copies the index file into its buffer and then closes it, instead of keeping it open for long, so the server can modify or delete the index file more easily. (Bug #22914974, Bug #26047119)

Is MySQL enterprise backup free?

How do I install MySQL enterprise backup on Windows?

What is MySQL enterprise edition?