The cluster restoration program is implemented as a separate
command-line utility ndb_restore, which can
normally be found in the MySQL bin
directory. This program reads the files created as a result of
the backup and inserts the stored information into the
database.
ndb_restore must be executed once for each
of the backup files that were created by the START
BACKUP command used to create the backup (see
Section 18.9.2, “Using The Management Client to Create a Backup”).
This is equal to the number of data nodes in the cluster at
the time that the backup was created.
Before using ndb_restore, it is recommended that the cluster be running in single user mode, unless you are restoring multiple data nodes in parallel. See Section 18.7.4, “Single User Mode”, for more information about single user mode.
Typical options for this utility are shown here:
ndb_restore [-cconnectstring] -nnode_id[-m] -bbackup_id-r [backup_path=]/path/to/backup/files
The -c option is used to specify a
connectstring which tells ndb_restore where
to locate the cluster management server. (See
Section 18.3.4.2, “The Cluster Connectstring”, for information
on connectstrings.) If this option is not used, then
ndb_restore attempts to connect to a
management server on localhost:1186. This
utility acts as a cluster API node, and so requires a free
connection “slot” to connect to the cluster
management server. This means that there must be at least one
[api] or [mysqld]
section that can be used by it in the cluster
config.ini file. It is a good idea to
keep at least one empty [api] or
[mysqld] section in
config.ini that is not being used for a
MySQL server or other application for this reason (see
Section 18.3.4.6, “Defining SQL and Other API Nodes”).
You can verify that ndb_restore is connected to the cluster by using the SHOW command in the ndb_mgm management client. You can also accomplish this from a system shell, as shown here:
shell> ndb_mgm -e "SHOW"
-n is used to specify the node ID of the data
node on which the backups were taken.
The first time you run the ndb_restore
restoration program, you also need to restore the metadata. In
other words, you must re-create the database tables —
this can be done by running it with the -m
option. Note that the cluster should have an empty database
when starting to restore a backup. (In other words, you should
start ndbd with --initial
prior to performing the restore.)
The -b option is used to specify the ID or
sequence number of the backup, and is the same number shown by
the management client in the Backup
message displayed upon completion of a backup. (See
Section 18.9.2, “Using The Management Client to Create a Backup”.)
backup_id completed
The path to the backup directory is required, and must include
the subdirectory corresponding to the ID backup of the backup
to be restored. For example, if the data node's
DataDir is
/var/lib/mysql-cluster, then the backup
directory is
/var/lib/mysql-cluster/BACKUP, and the
backup files for the backup with the ID 3 can be found in
/var/lib/mysql-cluster/BACKUP/BACKUP-3.
The path may be absolute or relative to the directory in which
the ndb_restore executable is located, and
may be optionally prefixed with backup_path=.
When restoring cluster backups, you must be sure to restore all data nodes from backups having the same backup ID. Using files from different backups will at best result in restoring the cluster to an inconsistent state, and may fail altogether.
It is not possible to restore a backup made from a newer version of MySQL Cluster using an older version of ndb_restore. You can restore a backup made from a newer version of MySQL to an older cluster, but you must use a copy of ndb_restore from the newer MySQL Cluster version to do so.
For example, to restore a cluster backup taken from a cluster running MySQL 5.0.45 to a cluster running MySQL Cluster 5.0.41, you must use a copy of ndb_restore from the 5.0.45 distribution.
It is possible to restore a backup to a database with a
different configuration than it was created from. For example,
suppose that a backup with backup ID 12,
created in a cluster with two database nodes having the node
IDs 2 and 3, is to be
restored to a cluster with four nodes. Then
ndb_restore must be run twice — once
for each database node in the cluster where the backup was
taken. However, ndb_restore cannot always
restore backups made from a cluster running one version of
MySQL to a cluster running a different MySQL version. See
Section 18.5.2, “Cluster Upgrade and Downgrade Compatibility”,
for more information.
For more rapid restoration, the data may be restored in
parallel, provided that there is a sufficient number of
cluster connections available. That is, when restoring to
multiple nodes in parallel, you must have an
[api] or [mysqld]
section in the cluster config.ini file
available for each concurrent ndb_restore
process. However, the data files must always be applied
before the logs.
Most of the options available for this program are shown in the following table:
| Long Form | Short Form | Description | Default Value |
--backup-id |
-b |
Backup sequence ID | 0 |
--backup_path |
None | Path to backup files | ./ |
--character-sets-dir |
None | Specify the directory where character set information can be found | None |
--connect, --connectstring, or
--ndb-connectstring
|
-c or -C
|
Set the connectstring in
[nodeid=
format |
localhost:1186 |
--core-file |
None | Write a core file in the event of an error | TRUE |
--debug |
-# |
Output debug log | d:t:O, |
--help or --usage
|
-? |
Display help message with available options and current values, then exit | [N/A] |
--ndb-mgmd-host |
None | Set the host and port in
format for the management server to connect to; this
is the same as --connect,
--connectstring, or
--ndb-connectstring, but without a
way to specify the nodeid
|
None |
--ndb-nodeid |
None | Specify a node ID for the ndb_restore process | 0 |
--ndb-optimized-node-selection |
None | Optimize selection of nodes for transactions | TRUE |
--ndb-shm |
None | Use shared memory connections when available | FALSE |
--nodeid |
-n |
Use backup files from node with the specified ID | 0 |
--parallelism |
-p |
Set from 1 to 1024 parallel transactions to be used during the restoration process | 128 |
--print |
None | Print metadata, data, and log to stdout
|
FALSE |
--print_data |
None | Print data to stdout
|
FALSE |
--print_log |
None | Print log to stdout
|
FALSE |
--print_meta |
None | Print metadata to stdout
|
FALSE |
--restore_data |
-r |
Restore data and logs | FALSE |
--restore_meta |
-m |
Restore table metadata | FALSE |
--version |
-V |
Output version information and exit | [N/A] |
Beginning with MySQL 5.0.40, several additional options are
available for use with the --print_data
option in generating data dumps, either to
stdout, or to a file. These are similar to
some of the options used with mysqldump,
and are shown in the following table:
| Long Form | Short Form | Description | Default Value |
--tab |
-T |
Creates dumpfiles, one per table, each named
.
Takes as its argument the path to the directory
where the files should be saved (required; use
. for the current directory). |
None |
--fields-enclosed-by |
None | String used to enclose all column values | None |
--fields-optionally-enclosed-by |
None | String used to enclose column values containing character data (such as
CHAR, VARCHAR,
BINARY, TEXT,
or ENUM) |
None |
--fields-terminated-by |
None | String used to separate column values |
\t (tab character) |
--hex |
None | Use hex format for binary values | [N/A] |
--lines-terminated-by |
None | String used to terminate each line |
\n (linefeed character) |
--append |
None | When used with --tab, causes the data to be appended to
existing files of the same name |
[N/A] |
If a table has no explicit primary key, then the output
generated when using the --print includes
the table's hidden primary key.
Beginning with MySQL 5.0.40, it is possible to restore selected databases, or to restore selected tables from a given database using the syntax shown here:
ndb_restoreother_optionsdb_name_1[db_name_2[,db_name_3][, ...] |tbl_name_1[,tbl_name_2][, ...]]
In other words, you can specify either of the following to be restored:
All tables from one or more databases
One or more tables from a single database
ndb_restore reports both temporary and
permanent errors. In the case of temporary errors, it may
able to recover from them. Beginning with MySQL 5.0.29, it
reports Restore successful, but encountered
temporary error, please look at configuration in
such cases.

User Comments
Add your own comment.