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:
- 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.
- 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.