The Geek Diary

How To Restore an NDBCluster Backup Using ndb_restore

by

Important: The native NDB Cluster backup only includes information for tables using the NDBCluster storage engine. If you need to restore views, stored procedures, stored functions, events, and tables using other storage engines, you must restore them from a mysqldump, mysqlpump, or other backup.

The backup created a set of files for each data node that was online at the time of the backup. The files are located below the directory specified by the BackupDataDir option in the directory BACKUP/BACKUP-[backup-id] where [backup-id] is the backup id of the backup. BackupDataDir defaults to the value of FileSystemPath which in turn defaults to DataDir. For example if BackupDataDir is set to /var/lib/cluster-data, then the backup with backup-id = 1 will be located in /var/lib/cluster-data/BACKUP/BACKUP-1/.

In the remainder of this post, it is assumed that the backup with backup-id = 1 is restored and the location of the backup is /var/lib/cluster-data/BACKUP/BACKUP-1/. Additionally, it will for this restore example be assumed there are four data nodes on both the cluster where the backup was created and where it is restored and the NodeId for the data nodes are 1, 2, 3, and 4; please adjust to reflect your systems. Finally replace … in –ndb_connectstring=… with the correct connect string for your management node(s).

With this location of the existing backup in mind, the steps to restore the backup are:

1. If necessary copy the backup to the cluster you need to restore the backup to.
2. Make sure the NDBCluster tables are all empty or do not exist.
3. If the tables do not exist, restore them. There are two options for this:

  1. Use the mysqldump –no-data backup. If the configuration of your cluster has changed with respect to the number of data nodes and/or LCP threads, you should use this method as it will ensure the number of partitions is set for the new configuration.
  2. Restore using ndb_restore. This should only be done for one node and must be completed before continuing: 
    shell$ ndb_restore --ndb_connectstring=... --nodeid=1 --restore_meta --backupid=1 --backup_path=/var/lib/cluster-data/BACKUP/BACKUP-1 --disable-indexes
4. Restore the data - each of these can be executed in parallel provided the cluster can keep up with the load:

NodeId = 1:

shell$ ndb_restore --ndb_connectstring=... --nodeid=1 --backupid=1 --restore_data --backup_path=/var/lib/cluster-data/BACKUP/BACKUP-1 --disable-indexes

NodeId = 2:

shell$ ndb_restore --ndb_connectstring=... --nodeid=2 --backupid=1 --restore_data --backup_path=/var/lib/cluster-data/BACKUP/BACKUP-1 --disable-indexes

NodeId = 3:

shell$ ndb_restore --ndb_connectstring=... --nodeid=3 --backupid=1 --restore_data --backup_path=/var/lib/cluster-data/BACKUP/BACKUP-1 --disable-indexes

NodeId = 4:

shell$ ndb_restore --ndb_connectstring=... --nodeid=4 --backupid=1 --restore_data --backup_path=/var/lib/cluster-data/BACKUP/BACKUP-1 --disable-indexes

If you are setting up a replication slave or need to perform point-in-time recovery, you must add the --restore_epoch for one of the restores.

5. Rebuild the indexes. These were disabled by the --disable-indexes option above. Recreating the indexes avoids errors due to the restore not being consistent at all points. Additionally rebuilding the indexes can with some configurations improve the restore performance. To rebuild the indexes, execute on just one node:

shell$ ndb_restore --ndb_connectstring=... --nodeid=1 --backupid=1 --backup_path=/var/lib/cluster-data/BACKUP/BACKUP-1 --rebuild-indexes

After this, the NDBCluster tables are ready to be used.

You May Also Like