MySQL Enterprise Backup 8.0 User's Guide  /  Getting Started with MySQL Enterprise Backup  /  What's New in MySQL Enterprise Backup 8.0?

Chapter 3 What's New in MySQL Enterprise Backup 8.0?

This chapter highlights the new features in MySQL Enterprise Backup 8.0, as well as any significant changes made to MySQL Enterprise Backup with the release of this series.

  • Offline backups are no longer supported. Using the old --no-connection and --connect-if-online options with MySQL Enterprise Backup will result in an error. The proper connection options must be supplied to MySQL Enterprise Backup when making a backup. The following options, used during offline backups, have also been removed :

    • --innodb_data_file_path

    • --innodb_log_files_in_group

    • --innodb_log_file_size

    • --innodb_page_size

    • --innodb_checksum_algorithm

    • --keyring_file_data

    • --keyring_okv_conf_dir

    • --relay-log-info-file

    • --master-info-file

    • --backup_innodb_log_files_in_group

    • --backup_innodb_log_file_size

    • --backup_innodb_undo_tablespaces

    • --backup_innodb_undo_logs

    • --backup_innodb_page_size

    • --backup_innodb_checksum_algorithm

  • The binary log for a backed-up server, instead of being restored always to the data directory on the target server, is now restored by default to the same location it was found on the backed-up server. It can also be restored to a different location specified with the new --log-bin option.

  • The relay log for a backed-up slave server, instead of being restored always to the data directory on the target slave server, is now restored by default to the same location it was found on the backed-up slave server. It can also be restored to a different location specified with the new --relay-log option.

  • A file now tracks information of external tablespaces for a backup or restore in JSON format. See description for tablespace_tracker in Table 1.1, “Types of Files in a Backup” for details.

  • A new option, --tls-version, specifies the protocols mysqlbackup permits for encrypted connections to MySQL servers.

  • MySQL Enterprise Firewall Overview is now supported.

  • The options --ssl and --ssl-verify-server-cert, already deprecated in MySQL Enterprise Backup 4.1, have now been removed. Use the --ssl-mode option instead to configure the security mode of your connection to the server.

  • HTTP Basic Authentication and non-chunked transfer are now supported for backup and restore using OpenStack Swift-compatible object storage services. See Section 19.15, “Cloud Storage Options” for details.

  • The buffer size for cloud transfers can now be specified using the new cloud-buffer-size option. See Section 19.15, “Cloud Storage Options” for details.

  • Servers' use of the keyring_encrypted_file and the keyring_aws plugins is now supported. Also, irrespective of the keyring plugin type that is used on the server, the keyring data is now stored in the backup in an encrypted file. See Chapter 6, Working with Encrypted InnoDB Tablespaces for details.

  • The server option --secure-auth, deprecated since MySQL 5.7.5, is no longer supported by mysqlbackup.

  • The backup_history table now includes a server_uuid column, which stores the value of the server_uuid of the backed up server.

  • Due to the new features and functions of MySQL Enterprise Backup 8.0, more privileges are now required for the user by which mysqlbackup connects to the MySQL Server. See Section 4.1.2, “Grant MySQL Privileges to Backup Administrator” for details.

  • For MySQL Enterprise Backup 8.0.12 and later:

    • When working with a Group Replication setup, mysqlbackup now makes the backup history available to all members of the server group by making sure that the backup_history table is updated on a primary node after each mysqlbackup operation. See Chapter 9, Using MySQL Enterprise Backup with Group Replication for details, including the resulting new user privilege requirement for mysqlbackup to connect to a server, regardless of whether the server belongs to a Group Replication setup.

    • OAuth is now supported for Oracle Cloud Infrastructure Object Storage client authentication. Two new options, --cloud-storage-url and --cloud-oauth-token, have been introduced for the purpose. See Section 19.15, “Cloud Storage Options” for details.

    • The storage engine of the mysql.backup_history table on a backed-up server has switched from CSV to InnoDB. See here for the special user privileges now required by mysqlbackup that are related to this change.

  • For MySQL Enterprise Backup 8.0.13 and later:

  • For MySQL Enterprise Backup 8.0.14 and later:

  • For MySQL Enterprise Backup 8.0.16 and later:

    • Near the end of the backup process, instead of locking the whole server instance for a brief period of time, mysqlbackup now applies these locks consecutively:

      1. A backup lock on the server instance, which blocks DDLs (except those on user-created temporary tables), but not DMLs on InnoDB tables.

      2. A FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK operation on all non-InnoDB tables, for copying the relevant ones among them into the backup. This step is skipped if no user created non-InnoDB tables exist.

      3. A brief blocking of logging activities on the server, for collecting logging-related information.

      See Section 1.4, “The Backup Process” for details. The removal of the lock on the whole server instance reduces disruption to the database service by the backup operation.

      Important

      The change requires that the BACKUP_ADMIN and SELECT privileges on all tables be granted to the user by which mysqlbackup connects to the server (the BACKUP_ADMIN privilege is automatically granted to users with the RELOAD privilege when an in-place upgrade to MySQL Server 8.0 from an earlier version is performed).

    • In addition to the requirement that the target data directory for a restore specified by --datadir must be non-existent or empty, mysqlbackup now enforces the same rule for the --innodb_data_home_dir, --innodb_log_group_home_dir, and --innodb_undo_directory options (the --force option cannot be used to override the requirement on the three options).

    • mysqlbackup now supports dynamic changes to undo tablespaces on the server being backed up. During a restore, the default undo tablespaces, as well as any non-default undo tablespaces resided in the backed-up server's data directory, are restored to the location pointed to by the mysqlbackup option innodb_undo_directory. Non-default, external undo tablespaces are restored to the locations they were found on the backed-up server. See descriptions for the undo log files for details.

    • mysqlbackup now supports encrypted InnoDB undo logs. The encrypted undo tablespaces are handled the same way as the encrypted tablespaces for InnoDB tables. See Chapter 6, Working with Encrypted InnoDB Tablespaces for details.

  • For MySQL Enterprise Backup 8.0.17 and later:

  • For MySQL Enterprise Backup 8.0.18 and later:

  • For MySQL Enterprise Backup 8.0.19 and later:

    • It is now safe to have DDL operations (CREATE TABLE, RENAME TABLE, DROP TABLE, ALTER TABLE, and operations that map to ALTER TABLE like CREATE INDEX) happening on the server in parallel with a backup operation; see details described here for some limitations. Due to this new feature, the user by which mysqlbackup connects to the MySQL server must now be granted the SELECT ON *.* privilege; see Section 4.1.2, “Grant MySQL Privileges to Backup Administrator”.

    • Master key rotation for binary log encryption on the server in between a full and an incremental backup, as well as between two incremental backups performed by mysqlbackup, is now supported. During an incremental backup, mysqlbackup now records encryption information for all the encrypted binary log files (including those already backed up in earlier full or incremental backups) unless the --skip-binlog option is used, in which case a warning is given that the older binary log files might become unrestorable.

      Also, the --skip-binlog option now makes binary log to be skipped not just for the current backup operation, but also for all subsequent incremental backups that are based on the current backup.

    • The logging for backup restore has been improved: at the steps for setting the sizes of the log files, the names of the log files are now included.

    • mysqlbackup now prints a stack trace after being terminated by a signal.

    • When mysqlbackup fails to connect to a server, the warning returned by mysqlbackup now includes the hostname and port number for TCP connections, and the socket information for socket connections. This is particularly helpful for a Group Replication setup, for which mysqlbackup might attempt to connect to more than one host.

    • The storage engine for the mysql.backup_progress table on a backed-up server has switched from CSV to InnoDB, and a composite index is now created on the table's backup_id, current_timestamp columns. Also, when working with a Group Replication setup, mysqlbackup now makes the backup_progress table available to all members of the server group by making sure that the table is updated on a primary node during each mysqlbackup operation.

      When MySQL Enterprise Backup 8.0.19 or later tries to perform its first full backup on a database, it automatically checks the format of the mysql.backup_progress table. If it detects that the table is in the old format (which means the server has been upgraded from 8.0.18 or earlier and has been backed up by MySQL Enterprise Backup before), it attempts to perform an update on the table automatically. New privileges for the mysqlbackup user on the server are required for the table upgrade; see Appendix E, Backup Progress Table Update for details.

    • mysqlbackup now includes the configuration files auto.cnf and mysqld-auto.cnf from a server in its backup (except for a TTS backup). They are restored to the target server's data directory as backup-auto.cnf and backup-mysqld-auto.cnf respectively. To use those files to configure your restored server, rename them to their original names before starting the server.

    • For the backup-to-image, extract, list-image, and copy-back-and-apply-log commands, any relative path specified with --backup-image is now taken to be relative to the current directory in which the command is run.