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.
Create the backup of the data. You can do this by invoking the ndb_mgm client
START BACKUPcommand from the system shell, like this:
$> ndb_mgm -e "START BACKUP 1"
This assumes that the desired backup ID is 1.
Create a backup of the schema. In NDB 7.5.2 and later, this step is necessary only if the total number of LCP threads or LQH threads per node group is changed.
$> mysqldump --no-data --routines --events --triggers --databases > myschema.sqlImportant
Once you have created the
NDBnative backup using ndb_mgm, you must not make any schema changes before creating the backup of the schema, if you do so.
Copy the backup directory to the new cluster. For example if the backup you want to restore has ID 1 and
/backups/node_, 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:
You should copy the entire directory to the new node.
If you needed to create a schema file, copy this to a location on an SQL node where it can be read by mysqld.
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:
Restore the schema.
If you created a separate schema backup file using mysqldump, import this file using the mysql client, similar to what is shown here:
$> mysql < myschema.sql
When importing the schema file, you may need to specify the
--passwordoptions (and possibly others) in addition to what is shown, in order for the mysql client to be able to connect to the MySQL server.
If you did not need to create a schema file, you can re-create the schema using ndb_restore
-m), similar to what is shown here:
$> ndb_restore --nodeid=1 --backupid=1 --restore-meta --backup-path=/backups/node_1/BACKUP/BACKUP-1
ndb_restore must be able to contact the management server; add the
--ndb-connectstringoption if and as needed to make this possible.
Restore the data. This needs to be done once for each data node in the original cluster, each time using that data node's node ID. Assuming that there were 4 data nodes originally, the set of commands required would look something like this:
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
These can be run in parallel.
Be sure to add the
--ndb-connectstringoption as needed.
Rebuild the indexes. These were disabled by the
--disable-indexesoption 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
As mentioned previously, you may need to add the
--ndb-connectstringoption, so that ndb_restore can contact the management server.