backup cluster [--backupid=backup_id] [--snapshotstart | --snapshotend] [--waitstarted | --waitcompleted] [--password-file=filepath]cluster_name This command creates a backup of the MySQL NDB Cluster namedcluster_name.backup cluster takes a backup of the cluster'sNDB tables only; tables using other MySQL storage engines (such asInnoDB orMyISAM) are ignored.
By default, this command uses the backup ID assigned and returned byndb_mgmd (see the discussions onbackup_id inUsing The NDB Cluster Management Client to Create a Backup for more information); you can override this behavior by specifying a backup ID using the--backupid option.
The--snapshotstart option causes the backup to match the state of the cluster when the backup began.
The--snapshotend option causes the backup to reflect the state of the cluster when the backup was finished. If neither option is specified, the MySQL Cluster Manager client acts as though--snapshotend had been used.
When the--waitstarted option is used, the MySQL Cluster Manager client waits until the backup has started before returning control to the user, after which the user can check the backup process's status with theshow status command and the--backup option.
When the--waitcompleted option is used, the MySQL Cluster Manager client waits until the backup process is complete before returning control to the user. If neither--waitstarted or--waitcompleted is specified, the client behaves as if--waitcompleted had been used.
mcm> backup cluster mycluster;+-------------------------------+| Command result |+-------------------------------+| Backup completed successfully |+-------------------------------+1 row in set (33.50 sec) You can verify that the backup was performed by checking the output oflist backups, as shown here:
mcm> list backups mycluster;+----------+--------+---------+----------------------+-------+---------+| BackupId | NodeId | Host | Timestamp | Parts | Comment |+----------+--------+---------+----------------------+-------+---------+| 1 | 1 | tonfisk | 2016-10-24 22:24:54Z | 1 | || 1 | 2 | tonfisk | 2016-10-24 22:24:54Z | 1 | || 2 | 1 | tonfisk | 2016-10-24 22:24:54Z | 1 | || 2 | 2 | tonfisk | 2016-10-24 22:24:54Z | 1 | |+----------+--------+---------+----------------------+-------+---------+4 rows in set (0.02 sec) Each row in the output represents a backupimage—that is, a set of backup files specific to a given backup of a named cluster on a given data node.Timestamp values are in UTC. The backup image is saved in the folderBackupDataDir/BACKUP/BACKUP-IdBackupDataDir is a cluster parameter. IfBackupDataDir is not specified, it takes up the value ofDataDir, so that the image is stored in the directoryDatadir/BACKUP/BACKUP-backup_id
It is possible to remove an unwanted backup from a given node by deleting this image directory and its contents. To remove a given backup completely, you must remove the corresponding image from each data node'sBACKUP directory. You can do this as long as a backup or restore operation is not in progress. It is not necessary to stop the cluster or MySQL Cluster Manager agent prior to removing the images.
TheBackupId is used withabort backup andrestore cluster.
For release 8.0.28 and later: MySQL Cluster Manager supports the creation ofNDB native encrypted cluster backups using AES-256-CBC. To create an encrypted backup, use the--password-file option toprovide a file that contains the password. SeeUsing The NDB Cluster Management Client to Create a Backup for restrictions on the choice of passwords. The password file must satisfy the following requirements:
The file must be present on the same host as themcmd agent that the client issuing the
backup clustercommand is connected to.A relative file path is considered relative to the working directory of themcmd agent mentioned in the last bullet.
On Unix-like platforms, the file should only be readable and writable by the file owner; on Windows platforms, it should not be readable by the Everyone group.
Logical Backup for NDB Table Metadata
To allow more flexibility for cluster reconfiguration during a restore, thebackup cluster command also creates a logical backup for the metadata of the NDB tables in the cluster. Use the--all option with thelist backups command to list all backups, including the logical backups for the NDB tables' metadata, which are marked by the comment“Schema”:
mcm> list backups --all newcluster;+----------+--------+---------+----------------------+------+---------+| BackupId | NodeId | Host | Timestamp | Part | Comment |+----------+--------+---------+----------------------+------+---------+| 1 | 1 | tonfisk | 2016-08-12 16:55:52Z | 1 | || 1 | 2 | tonfisk | 2016-08-12 16:55:52Z | 1 | || 1 | 3 | tonfisk | 2016-08-12 16:55:52Z | 1 | || 1 | 4 | tonfisk | 2016-08-12 16:55:52Z | 1 | || 1 | 50 | tonfisk | 2016-08-12 16:55:55Z | | Schema |+----------+--------+---------+----------------------+------+---------+5 rows in set (0.02 sec) The logical backup was created using themysqldump utility. The backup is saved with the file nameBACKUP- extension, to be found in the folderBackupID.mysql_nodeid.schema.sqlbackupdatadir/BACKUP/BACKUP-idbackupdatadir (notice that the name is in lowercase) is amysqld parameter used only for specifying the location of the logical backup created by MySQL Cluster Manager. Ifbackupdatadir is not specified using theset command with themcm client, the default value of/ is used, so that the logical backup is saved in the foldermcm_data_repository/clusters/clustername/mysqld_nodeid//.mcm_data_repository/clusters/clustername/mysqld_nodeid/BACKUP/BACKUP-Id
The following restrictions apply for the creation of the logical backups for NDB table metadata:
At least onemysqld node must be running on the cluster for the logical backup to be performed
No backup was created for anymysqld node that was not running.
Metadata for non-NDB tables are not backed up.
The logical backup is NOT a proper point-in-time backup—no DDL operations should be performed on the cluster when the backup process is running on the cluster, or the backed-up metadata will become inconsistent with the backed-up data.
The backup for the NDB table metadata is helpful for restoring data from a cluster to another one with a different configuration (for example, when the target cluster for restore has a different number of data nodes); seeSection 4.6.2.4, “Partial restore—data nodes added” andSection 4.6.2.5, “Restoring a Backup to a Cluster with Fewer Data Nodes” for some use cases.