Documentation Home
MySQL NDB Cluster 7.3-7.4
Related Documentation Download this Excerpt
PDF (US Ltr) - 3.6Mb
PDF (A4) - 3.6Mb Restoring to More Nodes Than the Original

The node ID specified for a given ndb_restore command is that of the node in the original backup and not that of the data node to restore it to. When performing a backup using the method described in this section, ndb_restore connects to the management server and obtains a list of data nodes in the cluster the backup is being restored to. The restored data is distributed accordingly, so that the number of nodes in the target cluster does not need to be to be known or calculated when performing the backup.


When changing the total number of LCP threads or LQH threads per node group, you should recreate the schema from backup created using mysqldump.

  1. Create the backup of the data. You can do this by invoking the ndb_mgm client START BACKUP command from the system shell, like this:

    $> ndb_mgm -e "START BACKUP 1"

    This assumes that the desired backup ID is 1.

  2. Create a backup of the schema (see also below):

    $> mysqldump --no-data --routines --events --triggers --databases > myschema.sql

    You must not make any schema changes between the first and second steps.

  3. Copy the backup directories from above to the new cluster. For example if the backup you want to restore is has ID 1 and BackupDataDir = /backups/node_nodeid, then the path to the backup on this node is /backups/node_1/BACKUP/BACKUP-1. Inside this directory there are three files, listed here:

    • BACKUP-1-0.1.Data

    • BACKUP-1.1.ctl

    • BACKUP-1.1.log

    You should copy the entire directory to the new node.

There is no requirement for the backup to be restored from a specific node or nodes.

To restore from the backup just created, perform the following steps:

  1. Restore the schema. Import the schema file using the mysql client, as shown here:

    $> mysql < myschema.sql
  2. Restore the data. The following commands can be run in parallel:

    ndb_restore --nodeid=1 --backupid=1 --restore-data --backup-path=/backups/node_1/BACKUP/BACKUP-1 --disable-indexes
    ndb_restore --nodeid=2 --backupid=1 --restore-data --backup-path=/backups/node_2/BACKUP/BACKUP-1 --disable-indexes
    ndb_restore --nodeid=3 --backupid=1 --restore-data --backup-path=/backups/node_3/BACKUP/BACKUP-1 --disable-indexes
    ndb_restore --nodeid=4 --backupid=1 --restore-data --backup-path=/backups/node_4/BACKUP/BACKUP-1 --disable-indexes
    ndb_restore --nodeid=5 --backupid=1 --restore-data --backup-path=/backups/node_5/BACKUP/BACKUP-1 --disable-indexes
    ndb_restore --nodeid=6 --backupid=1 --restore-data --backup-path=/backups/node_6/BACKUP/BACKUP-1 --disable-indexes
    ndb_restore --nodeid=7 --backupid=1 --restore-data --backup-path=/backups/node_7/BACKUP/BACKUP-1 --disable-indexes
    ndb_restore --nodeid=8 --backupid=1 --restore-data --backup-path=/backups/node_8/BACKUP/BACKUP-1 --disable-indexes

    Add the --ndb-connectstring option as needed.

    If you in 3. for example copied the backups from the old nodes having node IDs 1 and 2 to a new node whose node ID is 1, you should perform the two invocations of ndb_restore with --nodeid=1 and --nodeid=2 on the new node that has 1 as its node ID.

  3. Rebuild the indexes. These were disabled by the --disable-indexes option used in the commands just shown. Recreating the indexes avoids errors due to the restore not being consistent at all points. Rebuilding the indexes can also improve performance in some cases. To rebuild the indexes, execute the following command once, on a single node:

    $> ndb_restore --nodeid=1 --backupid=1 --backup-path=/backups/node_1/BACKUP/BACKUP-1 --rebuild-indexes

You should be aware that the supported number of partitions in each table depends on the number of data nodes, node groups, and LDM threads in the cluster. Other conditions (such as the values of MaxNoOfExecutionThreads, ThreadConfig, NoOfReplicas, and so on) being the same, a cluster with (for example) two data nodes supports fewer partitions than a cluster with eight data nodes supports. This means that using ndb_restore --restore-meta to restore the schema does not always work since this restores a given table with the same number of partitions as in the original; it is safer to restore the schema from a backup written by mysqldump—as in the example shown previously—when restoring to a cluster having fewer data nodes, LDM threads, or both, than were used in the original cluster.

The support for fewer partitions when restoring to a smaller cluster also means the maximum number of rows per table is lower.