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.6, “MySQL Cluster Single User Mode”, for more information about single user mode.
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 all MySQL Cluster programs, see Section 17.4.23, “Options Common to MySQL Cluster Programs”.
Table 17.14. ndb_restore Command Line Options
Format | Description | Introduction | Deprecated | Removed |
---|---|---|---|---|
--append | Append data to a tab-delimited file | 5.1.18 | ||
--backup_path=path | Path to backup files directory | 5.1.17 | ||
--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 | |||
--disable-indexes | Causes indexes from a backup to be ignored; may decrease time needed to restore data. | 5.1.41-ndb-7.1.2 | ||
--dont_ignore_systab_0 | Do not ignore system table during restore. Experimental only; not for production use | |||
--exclude-databases=db-list | List of one or more databases to exclude (includes those not named) | 5.1.32-ndb-6.4.3 | ||
--exclude-missing-columns | Causes columns from the backup version of a table that are missing from the version of the table in the database to be ignored. | 5.1.35-ndb-7.0.7 | ||
--exclude-tables=table-list | List of one or more tables to exclude (includes those in same database that are not not named); each table reference must include the database name | 5.1.32-ndb-6.4.3 | ||
--fields-enclosed-by=char | Fields are enclosed with the indicated character | 5.1.18 | ||
--fields-optionally-enclosed-by | Fields are optionally enclosed with the indicated character | 5.1.18 | ||
--fields-terminated-by=char | Fields are terminated by the indicated character | 5.1.18 | ||
--hex | Print binary types in hexadecimal format | 5.1.18 | ||
--include-databases=db-list | List of one or more databases to restore (excludes those not named) | 5.1.32-ndb-6.4.3 | ||
--include-tables=table-list | List of one or more tables to restore (excludes those in same database that are not named); each table reference must include the database name | 5.1.32-ndb-6.4.3 | ||
--lines-terminated-by=char | Lines are terminated by the indicated character | 5.1.18 | ||
--restore_meta | Restore metadata to NDB Cluster using the NDB API | |||
--ndb-nodegroup-map=map | Nodegroup map for NDBCLUSTER storage engine. Syntax: list of (source_nodegroup, destination_nodegroup) | |||
--no-binlog | If a mysqld is connected and using binary logging, do not log the restored data | 5.1.24-ndb-6.3.16 | ||
--no-restore-disk-objects | Do not restore Disk Data objects such as tablespaces and log file groups | |||
--no-upgrade | Do not upgrade array type for varsize attributes which do not already resize VAR data, and do not change column attributes | 5.1.19 | ||
--nodeid=# | Back up files from node with this ID | |||
--parallelism=# | Number of parallel transactions during restoration of data | |||
--preserve-trailing-spaces | Allow preservation of tailing spaces (including padding) when CHAR is promoted to VARCHAR or BINARY is promoted to VARBINARY | 5.1.23-ndb-6.3.8 | ||
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 | |||
--progress-frequency=# | Print status of restoration each given number of seconds | |||
--promote-attributes | Allow attributes to be promoted when restoring data from backup | 5.1.23-ndb-6.3.8 | ||
--rebuild-indexes | Causes multi-threaded ordered index rebuilding of indexes found in the backup. | 5.1.41-ndb-7.1.2 | ||
--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. | |||
--skip-table-check | Skip table structure check during restoring of data | 5.1.17 | ||
--tab=path | Creates a tab-separated .txt file for each table in the given path | 5.1.18 | ||
--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 17.3.2.3, “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.7, “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. You should also remove
manually any Disk Data files present in the data node's
DataDir
.)
It is possible to restore data without restoring table metadata. Prior to MySQL 5.1.17, ndb_restore did not perform any checks of table schemas; if a table was altered between the time the backup was taken and when ndb_restore was run, ndb_restore would still attempt to restore the data to the altered table.
Beginning with MySQL 5.1.17, the default behavior is for
ndb_restore to fail with an error if table
data do not match the table schema; this can be overridden
using the --skip-table-check
or
-s
option. Prior to MySQL 5.1.21, if this
option is used, then ndb_restore attempts
to fit data into the existing table schema, but the result of
restoring a backup to a table schema that does not match the
original is unspecified.
Beginning with MySQL Cluster NDB 6.3.8,
ndb_restore supports limited
attribute promotion in much the same
way that it is supported by MySQL replication; that is, data
backed up from a column of a given type can generally be
restored to a column using a “larger, similar”
type. For example, data from a CHAR(20)
column can be restored to a column declared as
VARCHAR(20)
,
VARCHAR(30)
, or
CHAR(30)
; data from a
MEDIUMINT
column can be
restored to a column of type
INT
or
BIGINT
. See
Section 16.4.1.5.2, “Replication of Columns Having Different Data Types”,
for a table of type conversions currently supported by
attribute promotion.
Attribute promotion by ndb_restore must be enabled explicitly, as follows:
Prepare the table to which the backup is to be restored.
ndb_restore cannot be used to
re-create the table with a different definition from the
original; this means that you must either create the
table manually, or alter the columns which you wish to
promote using ALTER TABLE
after restoring the table metadata but before restoring
the data.
Invoke ndb_restore with the
--promote-attributes
option (short form
-A
) when restoring the table data.
Attribute promotion does not occur if this option is not
used; instead, the restore operation fails with an
error.
In addition to --promote-attributes
, a
--preserve-trailing-spaces
option is also
available for use with ndb_restore
beginning with MySQL Cluster NDB 6.3.8. This option (short
form -R
) causes trailing spaces to be
preserved when promoting a CHAR
column to VARCHAR
or a
BINARY
column to
VARBINARY
. Otherwise, any
trailing spaces are dropped from column values when they are
inserted into the new columns.
Although you can promote CHAR
columns to VARCHAR
and
BINARY
columns to
VARBINARY
, you cannot promote
VARCHAR
columns to
CHAR
or
VARBINARY
columns to
BINARY
.
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.
--restore_epoch
(short form:
-e
) adds (or restores) epoch information to
the cluster replication status table. This is useful for
starting replication on a MySQL Cluster replication slave.
When this option is used, the row in the
mysql.ndb_apply_status
having
0
in the id
column is
updated if it already exists; such a row is inserted if it
does not already exist. (See
Section 17.6.9, “MySQL Cluster Backups With MySQL Cluster Replication”.)
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.1.17 and MySQL Cluster NDB 6.1.5, 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.1.17 and MySQL Cluster NDB 6.1.5,
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.2, “MySQL Cluster 5.1 and MySQL Cluster NDB 6.x/7.x 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 Cluster NDB 6.2.15 to a cluster running MySQL 5.1.20, you must use a copy of ndb_restore from the MySQL Cluster NDB 6.2.15 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.
Formerly, when using ndb_restore to restore
a backup made from a MySQL 5.0 cluster to a 5.1 cluster,
VARCHAR
columns were not
resized and were recreated using the 5.0 fixed format.
Beginning with MySQL 5.1.19, ndb_restore
recreates such VARCHAR
columns
using MySQL Cluster 5.1's variable-width format. Also
beginning with MySQL 5.1.19, this behavior can be overridden
using the --no-upgrade
option (short form:
-u
) when running
ndb_restore.
This option causes ndb_restore to print its
output to stdout
. Beginning with MySQL
5.1.18, 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.1.18 | |
Command-Line Format | --tab=path |
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.1.18 | |
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.1.18 | |
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.1.18 | |
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.1.18 | |
Command-Line Format | --hex |
If this option is used, all binary values are output in hexadecimal format.
Version Introduced | 5.1.18 | |
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.1.18 | |
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.
Beginning with MySQL 5.1.18, it is possible to restore selected databases, or to restore selected tables from a given database using the syntax shown here:
ndb_restoreother_options
db_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
--include-databases=
db_name
[,db_name
][,...]
Version Introduced | 5.1.32-ndb-6.4.3 | |
Command-Line Format | --include-databases=db-list |
|
Permitted Values | ||
Type | string |
|
Default |
|
--include-tables=
db_name.tbl_name
[,db_name.tbl_name
][,...]
Version Introduced | 5.1.32-ndb-6.4.3 | |
Command-Line Format | --include-tables=table-list |
|
Permitted Values | ||
Type | string |
|
Default |
|
Beginning with MySQL Cluster NDB 6.3.22 and MySQL Cluster NDB
6.4.3, you can (and should) use instead the
--include-databases
option or the
--include-tables
option for restoring only
specific databases or tables, respectively.
--include-databases
takes a comma-delimited
list of databases to be restored.
--include-tables
takes a comma-delimited list
of tables (in
format) to be restored.
database
.table
When --include-databases
or
--include-tables
is used, only those
databases or tables named by the option are restored; all
other databases and tables are excluded by
ndb_restore, and are not restored.
The following table shows several invocations of
ndb_restore using
--include-*
options (other options possibly
required have been omitted for clarity), and the effects these
have on restoring from a MySQL Cluster backup:
Option Used | Result |
---|---|
--include-databases=db1 |
Only tables in database db1 are restored; all tables
in all other databases are ignored |
--include-databases=db1,db2 (or
--include-databases=db1
--include-databases=db2 ) |
Only tables in databases db1 and
db2 are restored; all tables in all
other databases are ignored |
--include-tables=db1.t1 |
Only table t1 in database db1 is
restored; no other tables in db1 or
in any other database are restored |
--include-tables=db1.t2,db2.t1 (or
--include-tables=db1.t2
--include-tables=db2.t1 ) |
Only the table t2 in database db1
and the table t1 in database
db2 are restored; no other tables
in db1 , db2 , or
any other database are restored |
Beginning with MySQL Cluster NDB 6.3.29 and MySQL Cluster NDB
7.0.10, you can use these two options together. For example,
the following causes all tables in databases
db1
and db2
, together
with the tables t1
and
t2
in database db3
, to
be restored (and no other databases or tables):
shell> ndb_restore [...] --include-databases=db1,db2 --include-tables=db3.t1,db3.t2
(Again we have omitted other, possibly required, options in the example just shown.)
Prior to MySQL Cluster NDB 6.3.29 and MySQL Cluster NDB
7.0.10, multiple --include-*
options were
not handled correctly, and the result of the options shown
in the previous example was that only the tables
db3.t1
and db3.t2
were
actually restored. (Bug#48907)
--exclude-databases=
db_name
[,db_name
][,...]
Version Introduced | 5.1.32-ndb-6.4.3 | |
Command-Line Format | --exclude-databases=db-list |
|
Permitted Values | ||
Type | string |
|
Default |
|
--exclude-tables=
db_name.tbl_name
[,db_name.tbl_name
][,...]
Version Introduced | 5.1.32-ndb-6.4.3 | |
Command-Line Format | --exclude-tables=table-list |
|
Permitted Values | ||
Type | string |
|
Default |
|
Also beginning with MySQL Cluster NDB 6.3.22 and MySQL Cluster
NDB 6.4.3, it is possible to exclude from being restored one
or more databases or tables using the
ndb_restore options
--exclude-databases
and
--exclude-tables
.
--exclude-databases
takes a comma-delimited
list of one or more databases which should not be restored.
--exclude-tables
takes a comma-delimited list
of one or more tables (using
format) which should not be restored.
database
.table
When --exclude-databases
or
--exclude-tables
is used, only those
databases or tables named by the option are excluded; all
other databases and tables are restored by
ndb_restore.
This table shows several invocations of
ndb_restore usng
--exclude-*
options (other options possibly
required have been omitted for clarity), and the effects these
options have on restoring from a MySQL Cluster backup:
Option Used | Result |
---|---|
--exclude-databases=db1 |
All tables in all databases except db1 are restored;
no tables in db1 are restored |
--exclude-databases=db1,db2 (or
--exclude-databases=db1
--exclude-databases=db2 ) |
All tables in all databases except db1 and
db2 are restored; no tables in
db1 or db2 are
restored |
--exclude-tables=db1.t1 |
All tables except t1 in database
db1 are restored; all other tables
in db1 are restored; all tables in
all other databases are restored |
--exclude-tables=db1.t2,db2.t1 (or
--exclude-tables=db1.t2
--exclude-tables=db2.t1)
|
All tables in database db1 except for
t2 and all tables in database
db2 except for table
t1 are restored; no other tables in
db1 or db2 are
restored; all tables in all other databases are
restored |
Beginning with MySQL Cluster NDB 6.3.29 and MySQL Cluster NDB
7.0.10, you can use these two options together. For example,
the following causes all tables in all databases
except for databases
db1
and db2
, along with
the tables t1
and t2
in
database db3
, not to
be restored:
shell> ndb_restore [...] --exclude-databases=db1,db2 --exclude-tables=db3.t1,db3.t2
(Again, we have omitted other possibly necessary options in the interest of clarity and brevity from the example just shown.)
Prior to MySQL Cluster NDB 6.3.29 and MySQL Cluster NDB
7.0.10, multiple --exclude-*
options were
not handled correctly, with the result that the options
shown in the previous example caused ndb_restore to exclude
only the tables db3.t1
and
db3.t2
. (Bug#48907)
Beginning with MySQL Cluster NDB 6.3.29 and MySQL Cluster NDB
7.0.10, you can use --include-*
and
--exclude-*
options together, subject to the
following rules:
The actions of all --include-*
and
--exclude-*
options are cumulative.
All --include-*
and
--exclude-*
options are evaluated in the
order passed to ndb_restore, from right to left.
In the event of conflicting options, the first (rightmost) option takes precedence. In other words, the first option (going from right to left) that matches against a given database or table “wins”.
For example, the following set of options causes
ndb_restore to restore all tables from
database db1
except
db1.t1
, while restoring no other tables
from any other databases:
--include-databases=db1 --exclude-tables=db1.t1
However, reversing the order of the options just given simply
causes all tables from database db1
to be
restored (including db1.t1
, but no tables
from any other database), because the
--include-dabases
option, being farthest to
the right, is the first match against database
db1
and thus takes precedence over any
other option that matches db1
or any tables
in db1
:
--exclude-tables=db1.t1 --include-databases=db1
Prior to MySQL Cluster NDB 6.3.29 and MySQL Cluster NDB
7.0.10, it was not possible to use
--include-databases
or
--include-tables
together with
--exclude-databases
or
--exclude-tables
, as these combinations
were evaluated inconsistently. (Bug#48907)
Version Introduced | 5.1.35-ndb-7.0.7 | |
Command-Line Format | --exclude-missing-columns |
Beginning with MySQL Cluster NDB 6.3.26 and MySQL Cluster NDB
7.0.7, it is also possible to restore only selected table
columns using the --exclude-missing-columns
option. When this option is used,
ndb_restore ignores any columns missing
from tables being restored as compared to the versions of
those tables found in the backup. This option applies to all
tables being restored. If you wish to apply this option only
to selected tables or databases, you can use it in combination
with one or more of the options described in the previous
paragraph to do so, then restore data to the remaining tables
using a complementary set of these options.
Version Introduced | 5.1.41-ndb-7.1.2 | |
Command-Line Format | --disable-indexes |
Beginning with MySQL Cluster NDB 6.3.31, MySQL Cluster NDB 7.0.11, and MySQL CLuster NDB 7.1.2, you can use this option with ndb_restore to disable the indexes found in a backup for faster restoration of the data.
Version Introduced | 5.1.41-ndb-7.1.2 | |
Command-Line Format | --rebuild-indexes |
Beginning with MySQL Cluster NDB 6.3.31, MySQL Cluster NDB 7.0.11, and MySQL CLuster NDB 7.1.2, you can use this option with ndb_restore to cause multi-threaded rebuilding of the ordered indexes found in a backup during the restoration process.
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.1.12, it
reports Restore successful, but encountered
temporary error, please look at configuration
in
such cases.
After using ndb_restore to initialize a
MySQL Cluster for use in circular replication, binary logs
on the SQL node acting as the replication slave are not
automatically created, and you must cause them to be created
manually. In order to cause the binary logs to be created,
issue a SHOW TABLES
statement
on that SQL node before running START
SLAVE
.
This is a known issue with MySQL Cluster management, which we intend to address in a future release.
User Comments
Add your own comment.