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 17.5.3.2, “Using The MySQL Cluster 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 17.5.8, “MySQL Cluster Single User Mode”, for more information.
The following table includes options that are specific to the MySQL Cluster native backup restoration program ndb_restore. Additional descriptions follow the table. For options common to most MySQL Cluster programs (including ndb_restore), see Section 17.4.20, “Options Common to MySQL Cluster Programs — Options Common to MySQL Cluster Programs”.
Table 17.19. ndb_restore Options and Variables: MySQL 5.0
| Format | Description | Added / Removed |
|---|---|---|
| Same as connectstring | All MySQL 5.0 based releases | |
| Back up files from node with this ID | All MySQL 5.0 based releases | |
| Restore from the backup with the given ID | All MySQL 5.0 based releases | |
| Restore table data and logs into NDB Cluster using the NDB API | All MySQL 5.0 based releases | |
| Restore metadata to NDB Cluster using the NDB API | All MySQL 5.0 based releases | |
| Number of parallel transactions to use while restoring data | All MySQL 5.0 based releases | |
| Print metadata, data and log to stdout (equivalent to --print_meta --print_data --print_log) | All MySQL 5.0 based releases | |
| Print metadata to stdout | All MySQL 5.0 based releases | |
| Print data to stdout | All MySQL 5.0 based releases | |
| Print to stdout | All MySQL 5.0 based releases | |
| Path to backup files directory | ADDED: 5.0.38 | |
| Do not ignore system table during restore. Experimental only; not for production use | All MySQL 5.0 based releases | |
| Fields are enclosed with the indicated character | ADDED: 5.0.40 | |
| Fields are terminated by the indicated character | ADDED: 5.0.40 | |
| Fields are optionally enclosed with the indicated character | ADDED: 5.0.40 | |
| Lines are terminated by the indicated character | ADDED: 5.0.40 | |
| Print binary types in hexadecimal format | ADDED: 5.0.40 | |
| Creates a tab-separated .txt file for each table in the given path | ADDED: 5.0.40 | |
| Append data to a tab-delimited file | ADDED: 5.0.40 | |
| Level of verbosity in output | All MySQL 5.0 based releases |
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 17.3.2.2, “The MySQL 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 17.3.2.6, “Defining SQL and Other API Nodes in a MySQL Cluster”).
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
--restore_meta (-m) option.
Restoring the metdata need be done only on a single data node;
this is sufficient to restore it to the entire cluster. 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 17.5.3.2, “Using The MySQL Cluster Management Client to Create a Backup”.)
backup_id completed
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.
The path to the backup directory is required; this is supplied
to ndb_restore using the
--backup_path option, 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=.
Previous to MySQL 5.0.38, the path to the backup directory was
specified as shown here, with backup_path=
being optional:
[backup_path=]/path/to/backup/files
Beginning with MySQL 5.0.38, this syntax changed to
--backup_path=,
to conform more closely with options used by other MySQL
programs; /path/to/backup/files--backup_id is required, and there
is no short form for this option.
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 17.2.6, “Upgrading and Downgrading MySQL Cluster”, for more
information.
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.
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.
Normally, when restoring table data and metadata,
ndb_restore ignores the copy of the
NDB system table that is present in
the backup. --dont_ignore_systab_0 causes the
system table to be restored. This option is intended
for experimental and development use only, and is not
recommended in a production environment.
Determines the maximum number of parallel transactions that ndb_restore tries to use. By default, this is 128; the minimum is 1, and the maximum is 1024.
This option causes ndb_restore to output
NDB table data and logs.
This option causes ndb_restore to print
NDB table metadata. Generally, you
need only use this option when restoring the first data node of
a cluster; additional data nodes can obtain the metadata from
the first one.
This option causes ndb_restore to print all
metadata to stdout.
The --print_log option causes
ndb_restore to output its log to
stdout.
Causes ndb_restore to print all data,
metadata, and logs to stdout. Equivalent to
using the --print_data,
--print_meta, and
--print_log options
together.
Use of --print or any of the
--print_* options is in effect performing a
dry run. Including one or more of these options causes any
output to be redirected to stdout; in such
cases, ndb_restore makes no attempt to
restore data or metadata to a MySQL Cluster.
This option causes ndb_restore to direct its
output to stdout.
TEXT and
BLOB column values are always
truncated to the first 256 bytes in the output; this cannot
currrently be overridden when using
--print_data.
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
list:
| Version Introduced | 5.0.40 | ||
| Command-Line Format | --tab=path | ||
-T | |||
This option causes
--print_data to create
dump files, one per table, each named
.
It requires as its argument the path to the directory where
the files should be saved; use tbl_name.txt. for the
current directory.
| Version Introduced | 5.0.40 | ||
| Command-Line Format | --fields-enclosed-by=char | ||
| Permitted Values | |||
| Type | string | ||
| Default | | ||
Each column values are enclosed by the string passed to this option (regardless of data type; see next item).
--fields-optionally-enclosed-by=
string
| Version Introduced | 5.0.40 | ||
| Command-Line Format | --fields-optionally-enclosed-by | ||
| Permitted Values | |||
| Type | string | ||
| Default | | ||
The string passed to this option is used to enclose column
values containing character data (such as
CHAR,
VARCHAR,
BINARY,
TEXT, or
ENUM).
| Version Introduced | 5.0.40 | ||
| Command-Line Format | --fields-terminated-by=char | ||
| Permitted Values | |||
| Type | string | ||
| Default | \t (tab) | ||
The string passed to this option is used to separate column
values. The default value is a tab character
(\t).
| Version Introduced | 5.0.40 | ||
| Command-Line Format | --hex | ||
If this option is used, all binary values are output in hexadecimal format.
| Version Introduced | 5.0.40 | ||
| Command-Line Format | --fields-terminated-by=char | ||
| Permitted Values | |||
| Type | string | ||
| Default | \t (tab) | ||
This option specifies the string used to end each line of
output. The default is a linefeed character
(\n).
| Version Introduced | 5.0.40 | ||
| Command-Line Format | --append | ||
When used with the --tab
and --print_data
options, this causes the data to be appended to any existing
files having the same names.
If a table has no explicit primary key, then the output
generated when using the
--print_data option
includes the table's hidden primary key.
Sets the level for the verbosity of the output. The minimum is 0; the maximum is 255. The default value is 1.
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,[db_name[,...] |tbl_name[,tbl_name][,...]]
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
Error reporting.
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.