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 15.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 15.5.6, “MySQL Cluster Single User Mode”, for more information about single user mode.
The following table includes command options specific to the MySQL Cluster native backup restoration program ndb_restore. Additional descriptions follow the table. For options common to all MySQL Cluster programs, see Section 15.4.21, “Options Common to MySQL Cluster Programs”.
Table 15.14. ndb_restore Command Line Options
Format | Description | Introduction | Deprecated | Removed |
---|---|---|---|---|
--backupid=# | Restore from the backup with the given ID | |||
--connect | Same as connectstring | |||
--restore_data | Restore table data and logs into NDB Cluster using the NDB API | |||
--dont_ignore_systab_0 | Do not ignore system table during restore. Experimental only; not for production use | |||
--restore_meta | Restore metadata to NDB Cluster using the NDB API | |||
--no-restore-disk-objects | Do not restore Disk Data objects such as tablespaces and log file groups | |||
--nodeid=# | Back up files from node with this ID | |||
--parallelism=# | Number of parallel transactions during restoration of data | |||
Print metadata, data and log to stdout (equivalent to --print_meta --print_data --print_log) | ||||
--print_data | Print data to stdout | |||
--print_log | Print to stdout | |||
--print_metadata | Print metadata to stdout | |||
--restore_epoch | Restore epoch info into the status table. Convenient on a MySQL Cluster replication slave for starting replication. The row in mysql.ndb_apply_status with id 0 will be updated/inserted. | |||
--verbose=# | Control level of verbosity in output |
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 15.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 15.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 -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 15.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=
.
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 4.1.22 to a cluster running MySQL Cluster 4.1.20, you must use a copy of ndb_restore from the 4.1.22 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 15.2.6.2, “MySQL Cluster 4.1 Upgrade and Downgrade Compatibility”,
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 4.1.22 to a cluster running MySQL Cluster 4.1.18, you must use a copy of ndb_restore from the 4.1.22 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.
If a table has no explicit primary key, then the output
generated when using the --print
includes
the table's hidden primary key.
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 4.1.22, it
reports Restore successful, but encountered
temporary error, please look at configuration
in
such cases.
User Comments
Add your own comment.