3.6.2.4 Partial restore—data nodes added

A partial restore can also be performed when new data nodes have been added to a MySQL NDB Cluster following a backup. In this case, you can exclude the new nodes using --skip-nodeid when executing the restore cluster command. Consider the MySQL NDB Cluster named mycluster as shown in the output of the following show status command:

mcm> show status -r mycluster;
+--------+----------+----------+---------+-----------+-----------+
| NodeId | Process  | Host     | Status  | Nodegroup | Package   |
+--------+----------+----------+---------+-----------+-----------+
| 49     | ndb_mgmd | tonfisk  | stopped |           | mypackage |
| 1      | ndbd     | tonfisk  | stopped | 0         | mypackage |
| 2      | ndbd     | tonfisk  | stopped | 0         | mypackage |
| 50     | mysqld   | tonfisk  | stopped |           | mypackage |
| 51     | mysqld   | tonfisk  | stopped |           | mypackage |
| 52     | ndbapi   | *tonfisk | added   |           |           |
| 53     | ndbapi   | *tonfisk | added   |           |           |
+--------+----------+----------+---------+-----------+-----------+
7 rows in set (0.03 sec)

The output of list backups shows us the available backup images for this cluster:

mcm> list backups mycluster;
+----------+--------+---------+---------------------+---------+
| BackupId | NodeId | Host    | Timestamp           | Comment |
+----------+--------+---------+---------------------+---------+
| 1        | 1      | tonfisk | 2012-12-04 12:03:52 |         |
| 1        | 2      | tonfisk | 2012-12-04 12:03:52 |         |
| 2        | 1      | tonfisk | 2012-12-04 12:04:15 |         |
| 2        | 2      | tonfisk | 2012-12-04 12:04:15 |         |
| 3        | 1      | tonfisk | 2012-12-04 12:17:41 |         |
| 3        | 2      | tonfisk | 2012-12-04 12:17:41 |         |
| 4        | 1      | tonfisk | 2012-12-12 14:24:35 |         |
| 4        | 2      | tonfisk | 2012-12-12 14:24:35 |         |
+----------+--------+---------+---------------------+---------+
8 rows in set (0.06 sec)

Now suppose that, at a later point in time, 2 data nodes have been added to mycluster using an add process command. The show status output for mycluster now looks like this:

mcm> show status -r mycluster;
+--------+----------+----------+---------+-----------+-----------+
| NodeId | Process  | Host     | Status  | Nodegroup | Package   |
+--------+----------+----------+---------+-----------+-----------+
| 49     | ndb_mgmd | tonfisk  | running |           | mypackage |
| 1      | ndbd     | tonfisk  | running | 0         | mypackage |
| 2      | ndbd     | tonfisk  | running | 0         | mypackage |
| 50     | mysqld   | tonfisk  | running |           | mypackage |
| 51     | mysqld   | tonfisk  | running |           | mypackage |
| 52     | ndbapi   | *tonfisk | added   |           |           |
| 53     | ndbapi   | *tonfisk | added   |           |           |
| 3      | ndbd     | tonfisk  | running | 1         | mypackage |
| 4      | ndbd     | tonfisk  | running | 1         | mypackage |
+--------+----------+----------+---------+-----------+-----------+
9 rows in set (0.01 sec)

Since nodes 3 and 4 were not included in the backup, we need to exclude them when performing the restore. You can cause restore cluster to skip multiple data nodes by specifying a comma-separated list of node IDs with the --skip-nodeid option. Assume that we have just cleared mycluster of MySQL NDB Cluster data using the mcm client commands stop cluster and start cluster --initial as described previously in this section; then we can restore mycluster (now having 4 data nodes numbered 1, 2, 3, and 4) from backup number 4 (made when mycluster had only 2 data nodes numbered 1 and 2) as shown here:

mcm> restore cluster --backupid=4 --skip-nodeid=3,4 mycluster;
+--------------------------------+
| Command result                 |
+--------------------------------+
| Restore completed successfully |
+--------------------------------+
1 row in set (17.61 sec)

No data is distributed to the skipped (new) nodes; you must force nodes 3 and 4 to be included in a redistribution of the data using ALTER ONLINE TABLE ... REORGANIZE PARTITION as described previously in this section.

For MySQL Cluster Manager 1.4.1 and later: An alternative to generating and running the ALTER ONLINE TABLE ... REORGANIZE PARTITION steps is to make use of the logical backup of the NDB tables' metadata, which is part of the cluster backup created by MySQL Cluster Manager. To do this, before you run the restore cluster step outlined above:

1. Locate the logical backup for the metadata; see Locations of backup files in Section 3.6.2.5, “Restoring a Backup to a Cluster with Fewer Data Nodes” for instructions.

2. Restore the logical backup; see Restore the Logical Backup of NDB Table Metadata in Section 3.6.2.5, “Restoring a Backup to a Cluster with Fewer Data Nodes” for instructions.

You can then run the restore cluster step, and the data is going to be redistributed across all the data nodes, without the need for further manual intervention.