Restoring a Backup
The previous sections cover how to perform a backup operation. But a backup is useless if you cannot properly recover from it. The recovery process is relatively simple for both of the backup methods discussed. However, you should generally practice the process a few times before you attempt to do it on a production system.
Restoring a Backup by Using Native Hot Backup
To restore a backup made by using the native hot backup tool, you use the ndb_restore program that comes with the MySQL Cluster installation. This program reads the backup files and loads the data and structure into a running cluster. The cluster that the data is being loaded into can have a different topography than the original cluster. For example, if you want to increase from two data nodes to four data nodes, you can do it without any problems when you use this backup method.
ndb_restore connects to the cluster in the same manner as a MySQL server does, and then it effectively re-issues the CREATE and INSERT statements needed to re-create your tables. Because it connects directly to the cluster, you need to make sure you have an extra [mysqld] section in your cluster configuration file for it. You still need to manually re-create your databases and other non-clustered objects after you restore this backup.
These are the steps for restoring a backup taken by the native hot backup:
|
1. |
Enter single-user mode for the node ID you plan to use for ndb_restore (or otherwise guarantee that no one else is using the cluster).
|
|
2. |
From within the BACKUP-# directory, use the ndb_restore tool to restore the metadata (that is, table structure) of the system by using -m or --restore_meta.
|
|
3. |
Use ndb_restore to restore the data from the fragment to the tables, with the -r or --restore_data option.
|
|
4. |
Repeat step 3 for each of the other data nodes. (For example, if you had four data nodes when you made the backup, you need to perform step 3 four times.)
|
|
5. |
Leave single-user mode. Your cluster is now ready to be used.
|
When using ndb_restore, you are required to specify a few options.
- -b or backupid You use this option to specify the backup ID that needs to be restored. The backup ID is the number immediately after the BACKUP word. For example, with BACKUP-7.2.ctl, the backup ID is 7.
- The original node ID for the backup Again, you can get this ID from the filename; it is the number listed immediately before the file extension. For example, with BACKUP-7.2.ctl, the original node ID is 2.
- -m, -r, or both You use these options to specify whether to restore the schema, the data, or both at the same time.
The following is an example of a session involving restoring from a native backup of two nodes
shell:~/ndb/BACKUP/BACKUP-1$ ls -l total 432 -rw-r----- 1 user group 99568 Nov 25 17:19 BACKUP-1-0.2.Data -rw-r----- 1 user group 91956 Nov 25 17:19 BACKUP-1-0.3.Data -rw-r----- 1 user group 6384 Nov 25 17:19 BACKUP-1.2.ctl -rw-r----- 1 user group 44 Nov 25 17:19 BACKUP-1.2.log -rw-r----- 1 user group 6384 Nov 25 17:19 BACKUP-1.3.ctl -rw-r----- 1 user group 44 Nov 25 17:19 BACKUP-1.3.log shell:~/ndb/BACKUP/BACKUP-1$ ndb_restore -m -b 1 -n 2 Ndb version in backup files: Version 5.0.13 Connected to ndb!! Successfully restored table world/def/countrylanguage Successfully restored table world/def/country Successfully created index PRIMARY on countrylanguage Successfully created index PRIMARY on country NDBT_ProgramExit: 0 - OK shell:~/ndb/BACKUP/BACKUP-1$ ndb_restore -r -b 1 -n 2 Ndb version in backup files: Version 5.0.13 Connected to ndb!! _____________________________________________________ Processing data in table: world/def/countrylanguage(3) fragment 0 _____________________________________________________ Processing data in table: world/def/country(2) fragment 0 _____________________________________________________ Processing data in table: sys/def/NDB$EVENTS_0(1) fragment 0 _____________________________________________________ Processing data in table: sys/def/SYSTAB_0(0) fragment 0 Restored 627 tuples and 0 log entries NDBT_ProgramExit: 0 - OK shell:~/ndb/BACKUP/BACKUP-1$ ndb_restore -r -b 1 -n 3 Ndb version in backup files: Version 5.0.13 Connected to ndb!! _____________________________________________________ Processing data in table: world/def/countrylanguage(3) fragment 1 _____________________________________________________ Processing data in table: world/def/country(2) fragment 1 _____________________________________________________ Processing data in table: sys/def/NDB$EVENTS_0(1) fragment 1 ______________________________________________________ Processing data in table: sys/def/SYSTAB_0(0) fragment 1 Restored 596 tuples and 0 log entries NDBT_ProgramExit: 0 - OK
Restoring a Backup Made Using mysqldump
To restore a backup made by using mysqldump, you simply redirect the file you saved the output to into the mysql command-line client. This causes the client to reissue all the SQL commands needed to restore your database objects and data (if you made a backup of the data). Generally, you need to make sure the cluster isn't in use when you are doing this.
You need to log in to the MySQL server by using normal user account privileges (normally as the root user with a password).
The following is an example of this command:
shell> mysql -u root -p < file.sql
If the command returns, you know the backup has completed successfully. If it gives an error, something has gone wrong (possibly version incompatibilities or something similar).
Keep in mind that if this restoration is creating non-clustered objects, such as stored procedures and triggers, you need to follow this procedure on each MySQL server to restore them all fully. Chapter4 provides some examples of scripts you can use as a basis to do this easily.
When doing this type of restoration, you might want to consider setting the MySQL server variable ndb_use_transactions to false or off. This allows you to not have any problems with REDO log segments.
Speeding Up Restoration
When restoring data, the biggest thing you can do to attempt to speed things up is to do the restoration in parallel. Because a cluster has many data nodes, you generally want to do many loads at the same time to take advantage of them and to avoid bottlenecks such as network bottlenecks.
With native backups, this is quite easy because the data for your tables is split into many files (one for each data node). You can simply restore the metadata from one and then restore the data from all the nodes at the same time. The exact number of restorations to do at once depends on the number of data nodes you have, network settings, and so on. We recommend that you do some simple testing to determine the ideal number of restorations to do at once. Keep in mind that each ndb_restore running at once requires its own [mysqld] slot in the cluster configuration.
Getting the load to occur in parallel with mysqldump takes a bit of effort. We recommend possibly splitting each table into a different dump file and then loading it in that way. If you are just dumping a single database, you can use the --tab option for mysqldump to produce a separate file for each table, which can then possibly make it easier to load in parallel.