MySQL 5.6 Reference Manual Including MySQL NDB Cluster 7.3-7.4 Reference Guide
The NDB 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.
Beginning with NDB 7.3.25 and 7.4.24, this program no longer
prints NDBT_ProgramExit: ...
when it
finishes its run. Applications depending on this behavior
should be modified accordingly when upgrading from earlier
releases.
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.5.8.2, “Using The NDB 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 18.5.6, “NDB Cluster Single User Mode”, for more information.
The following table includes options that are specific to the NDB Cluster native backup restoration program ndb_restore. Additional descriptions follow the table. For options common to most NDB Cluster programs (including ndb_restore), see Section 18.4.29, “Options Common to NDB Cluster Programs — Options Common to NDB Cluster Programs”.
Table 18.32 Command-line options for the ndb_restore program
Format | Description | Added, Deprecated, or Removed |
---|---|---|
Append data to tab-delimited file | (Supported in all MySQL 5.6 based releases) |
|
Path to backup files directory | (Supported in all MySQL 5.6 based releases) |
|
Restore from backup having this ID | (Supported in all MySQL 5.6 based releases) |
|
Alias for --connectstring | (Supported in all MySQL 5.6 based releases) |
|
Causes indexes from backup to be ignored; may decrease time needed to restore data | (Supported in all MySQL 5.6 based releases) |
|
Do not ignore system table during restore; experimental only; not for production use | (Supported in all MySQL 5.6 based releases) |
|
List of one or more databases to exclude (includes those not named) | (Supported in all MySQL 5.6 based releases) |
|
If TRUE (default), do not restore any intermediate tables (having names prefixed with '#sql-') that were left over from copying ALTER TABLE operations | ADDED: NDB 7.3.6 |
|
Causes columns from backup version of table that are missing from version of table in database to be ignored | (Supported in all MySQL 5.6 based releases) |
|
Causes tables from backup that are missing from database to be ignored | ADDED: NDB 7.3.7 |
|
List of one or more tables to exclude (includes those in same database that are not named); each table reference must include database name | (Supported in all MySQL 5.6 based releases) |
|
Fields are enclosed by this character | (Supported in all MySQL 5.6 based releases) |
|
Fields are optionally enclosed by this character | (Supported in all MySQL 5.6 based releases) |
|
Fields are terminated by this character | (Supported in all MySQL 5.6 based releases) |
|
Print binary types in hexadecimal format | (Supported in all MySQL 5.6 based releases) |
|
List of one or more databases to restore (excludes those not named) | (Supported in all MySQL 5.6 based releases) |
|
List of one or more tables to restore (excludes those in same database that are not named); each table reference must include database name | (Supported in all MySQL 5.6 based releases) |
|
Lines are terminated by this character | (Supported in all MySQL 5.6 based releases) |
|
Allow lossy conversions of column values (type demotions or changes in sign) when restoring data from backup | (Supported in all MySQL 5.6 based releases) |
|
If mysqld is connected and using binary logging, do not log restored data | (Supported in all MySQL 5.6 based releases) |
|
Do not restore objects relating to Disk Data | (Supported in all MySQL 5.6 based releases) |
|
Do not upgrade array type for varsize attributes which do not already resize VAR data, and do not change column attributes | (Supported in all MySQL 5.6 based releases) |
|
Nodegroup map for NDBCLUSTER storage engine; syntax: list of (source_nodegroup, destination_nodegroup) | (Supported in all MySQL 5.6 based releases) |
|
ID of node where backup was taken | (Supported in all MySQL 5.6 based releases) |
|
Number of parallel transactions to use while restoring data | (Supported in all MySQL 5.6 based releases) |
|
Allow preservation of trailing spaces (including padding) when promoting fixed-width string types to variable-width types | (Supported in all MySQL 5.6 based releases) |
|
Print metadata, data, and log to stdout (equivalent to --print-meta --print-data --print-log) | (Supported in all MySQL 5.6 based releases) |
|
Print data to stdout | (Supported in all MySQL 5.6 based releases) |
|
Print log to stdout | (Supported in all MySQL 5.6 based releases) |
|
Print metadata to stdout | (Supported in all MySQL 5.6 based releases) |
|
Print status of restore each given number of seconds | (Supported in all MySQL 5.6 based releases) |
|
Allow attributes to be promoted when restoring data from backup | (Supported in all MySQL 5.6 based releases) |
|
Causes multithreaded rebuilding of ordered indexes found in backup; number of threads used is determined by setting BuildIndexThreads | (Supported in all MySQL 5.6 based releases) |
|
Restore table data and logs into NDB Cluster using NDB API | (Supported in all MySQL 5.6 based releases) |
|
Restore epoch info into status table; useful on replica cluster for starting replication; updates or inserts row in mysql.ndb_apply_status with ID 0 | (Supported in all MySQL 5.6 based releases) |
|
Restore metadata to NDB Cluster using NDB API | (Supported in all MySQL 5.6 based releases) |
|
Restore MySQL privilege tables that were previously moved to NDB | (Supported in all MySQL 5.6 based releases) |
|
Restore to differently named database | (Supported in all MySQL 5.6 based releases) |
|
Ignore missing blob tables in backup file | (Supported in all MySQL 5.6 based releases) |
|
Skip table structure check during restore | (Supported in all MySQL 5.6 based releases) |
|
Causes schema objects not recognized by ndb_restore to be ignored when restoring backup made from newer NDB version to older version | (Supported in all MySQL 5.6 based releases) |
|
Creates a tab-separated .txt file for each table in path provided | (Supported in all MySQL 5.6 based releases) |
|
Level of verbosity in output | (Supported in all MySQL 5.6 based releases) |
Typical options for this utility are shown here:
ndb_restore [-cconnection_string
] -nnode_id
-bbackup_id
\ [-m] -r --backup-path=/path/to/backup/files
Normally, when restoring from an NDB Cluster backup,
ndb_restore requires at a minimum the
--nodeid
(short form:
-n
),
--backupid
(short form:
-b
), and
--backup-path
options. In
addition, when ndb_restore is used to restore
any tables containing unique indexes, you must include
--disable-indexes
or
--rebuild-indexes
. (Bug
#57782, Bug #11764893)
The -c
option is used to specify a connection
string which tells ndb_restore
where to
locate the cluster management server (see
Section 18.3.3.3, “NDB Cluster Connection Strings”). 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.3.7, “Defining SQL and Other API Nodes in an NDB 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"
In NDB 7.3.11 and NDB 7.4.8 only, when
ndb_restore is used to restore any tables
containing unique indexes, you must include
--disable-indexes
or
--rebuild-indexes
. (Bug
#57782, Bug #11764893) This is not a requirement in later
versions. (Bug #22345748)
More detailed information about all options used by ndb_restore can be found in the following list:
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.
Command-Line Format | --backup-path=dir_name |
---|---|
Type | Directory name |
Default Value | ./ |
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 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 storage
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 storage 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.2.7, “Upgrading and Downgrading NDB Cluster”, for more
information.
It is not possible to restore a backup made from a newer version of NDB 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 NDB Cluster version to do so.
For example, to restore a cluster backup taken from a cluster running NDB Cluster 7.4.32 to a cluster running NDB Cluster 7.3.33, you must use the ndb_restore that comes with the NDB Cluster 7.4.32 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.
Command-Line Format | --backupid=# |
---|---|
Type | Numeric |
Default Value | none |
This 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.5.8.2, “Using The NDB 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 at best results in restoring the cluster to an inconsistent state, and may fail altogether.
Command-Line Format | --connect |
---|---|
Type | String |
Default Value | localhost:1186 |
Alias for
--ndb-connectstring
.
Command-Line Format | --disable-indexes |
---|
Disable restoration of indexes during restoration of the
data from a native NDB
backup.
Afterwards, you can restore indexes for all tables at once
with multithreaded building of indexes using
--rebuild-indexes
, which
should be faster than rebuilding indexes concurrently for
very large tables.
Command-Line Format | --dont-ignore-systab-0 |
---|
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.
Command-Line Format | --exclude-databases=db-list |
---|---|
Type | String |
Default Value |
|
Comma-delimited list of one or more databases which should not be restored.
This option is often used in combination with
--exclude-tables
; see
that option's description for further information and
examples.
--exclude-intermediate-sql-tables[
=TRUE|FALSE]
Command-Line Format | --exclude-intermediate-sql-tables[=TRUE|FALSE] |
---|---|
Introduced | 5.6.17-ndb-7.3.6 |
Type | Boolean |
Default Value | TRUE |
When performing copying ALTER
TABLE
operations, mysqld
creates intermediate tables (whose names are prefixed with
#sql-
). When TRUE
, the
--exclude-intermediate-sql-tables
option
keeps ndb_restore from restoring such
tables that may have been left over from these operations.
This option is TRUE
by default.
This option was introduced in NDB 7.3.6. (Bug #17882305)
Command-Line Format | --exclude-missing-columns |
---|
It is possible to restore only selected table columns using
this option, which causes ndb_restore to
ignore 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 --include-*
or
--exclude-*
options described elsewhere in
this section to do so, then restore data to the remaining
tables using a complementary set of these options.
Command-Line Format | --exclude-missing-tables |
---|---|
Introduced | 5.6.21-ndb-7.3.7 |
It is possible to restore only selected tables using this option, which causes ndb_restore to ignore any tables from the backup that are not found in the target database.
This option was introduced in NDB 7.3.7.
Command-Line Format | --exclude-tables=table-list |
---|---|
Type | String |
Default Value |
|
List of one or more tables to exclude; each table reference
must include the database name. Often used together with
--exclude-databases
.
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 an NDB Cluster backup:
Table 18.33 Several invocations of ndb_restore using --exclude-* options, and the effects these options have on restoring from an NDB Cluster backup.
Option | 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 |
You can use these two options together. For example, the
following causes all tables in all databases
except for databases
db1
and db2
, and
tables t1
and t2
in
database db3
, 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.)
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-databases
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
Command-Line Format | --fields-enclosed-by=char |
---|---|
Type | String |
Default Value |
|
Each column value is enclosed by the string passed to this
option (regardless of data type; see the description of
--fields-optionally-enclosed-by
).
--fields-optionally-enclosed-by
Command-Line Format | --fields-optionally-enclosed-by |
---|---|
Type | String |
Default Value |
|
The string passed to this option is used to enclose column
values containing character data (such as
CHAR
,
VARCHAR
,
BINARY
,
TEXT
, or
ENUM
).
Command-Line Format | --fields-terminated-by=char |
---|---|
Type | String |
Default Value | \t (tab) |
The string passed to this option is used to separate column
values. The default value is a tab character
(\t
).
Command-Line Format | --hex |
---|
If this option is used, all binary values are output in hexadecimal format.
Command-Line Format | --include-databases=db-list |
---|---|
Type | String |
Default Value |
|
Comma-delimited list of one or more databases to restore.
Often used together with
--include-tables
; see
the description of that option for further information and
examples.
Command-Line Format | --include-tables=table-list |
---|---|
Type | String |
Default Value |
|
Comma-delimited list of tables to restore; each table reference must include the database name.
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 an NDB Cluster backup:
Table 18.34 Several invocations of ndb_restore using --include-* options, and their effects on restoring from an NDB Cluster backup.
Option | 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 |
You can also 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.)
It also possible to restore only selected databases, or
selected tables from a single database, without any
--include-*
(or
--exclude-*
) options, 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
Command-Line Format | --lines-terminated-by=char |
---|---|
Type | String |
Default Value | \n (linebreak) |
Specifies the string used to end each line of output. The
default is a linefeed character (\n
).
Command-Line Format | --lossy-conversions |
---|---|
Type | Boolean |
Default Value | FALSE (If option is not used) |
This option is intended to complement the
--promote-attributes
option. Using --lossy-conversions
allows
lossy conversions of column values (type demotions or
changes in sign) when restoring data from backup. With some
exceptions, the rules governing demotion are the same as for
MySQL replication; see
Section 17.4.1.9.2, “Replication of Columns Having Different Data Types”,
for information about specific type conversions currently
supported by attribute demotion.
ndb_restore reports any truncation of data that it performs during lossy conversions once per attribute and column.
Command-Line Format | --no-binlog |
---|
This option prevents any connected SQL nodes from writing data restored by ndb_restore to their binary logs.
Command-Line Format | --no-restore-disk-objects |
---|---|
Type | Boolean |
Default Value | FALSE |
This option stops ndb_restore from restoring any NDB Cluster Disk Data objects, such as tablespaces and log file groups; see Section 18.5.10, “NDB Cluster Disk Data Tables”, for more information about these.
Command-Line Format | --no-upgrade |
---|
When using ndb_restore to restore a
backup, VARCHAR
columns
created using the old fixed format are resized and recreated
using the variable-width format now employed. This behavior
can be overridden by specifying
--no-upgrade
.
Command-Line Format | --ndb-nodegroup-map=map |
---|
This option can be used to restore a backup taken from one
node group to a different node group. Its argument is a list
of the form
.
source_node_group
,
target_node_group
Command-Line Format | --nodeid=# |
---|---|
Type | Numeric |
Default Value | none |
Specify the node ID of the data node on which the backup was taken.
When restoring to a cluster with different number of data nodes from that where the backup was taken, this information helps identify the correct set or sets of files to be restored to a given node. (In such cases, multiple files usually need to be restored to a single data node.) See Section 18.4.22.2, “Restoring to a different number of data nodes”, for additional information and examples.
Command-Line Format | --parallelism=# |
---|---|
Type | Numeric |
Default Value | 128 |
Minimum Value | 1 |
Maximum Value | 1024 |
ndb_restore uses single-row transactions to apply many rows concurrently. This parameter determines the number of parallel transactions (concurrent rows) that an instance of ndb_restore tries to use. By default, this is 128; the minimum is 1, and the maximum is 1024.
The work of performing the inserts is parallelized across
the threads in the data nodes involved. This mechanism is
employed for restoring bulk data from the
.Data
file—that is, the fuzzy
snapshot of the data; it is not used for building or
rebuilding indexes. The change log is applied serially;
index drops and builds are DDL operations and handled
separately. There is no thread-level parallelism on the
client side of the restore.
--preserve-trailing-spaces
,
-P
Command-Line Format | --preserve-trailing-spaces |
---|
Cause trailing spaces to be preserved when promoting a
fixed-width character data type to its variable-width
equivalent—that is, when promoting a
CHAR
column value to
VARCHAR
, or a
BINARY
column value to
VARBINARY
. Otherwise, any
trailing spaces are dropped from such column values when
they are inserted into the new columns.
Command-Line Format | --print |
---|---|
Type | Boolean |
Default Value | FALSE |
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 an NDB Cluster.
Command-Line Format | --print-data |
---|---|
Type | Boolean |
Default Value | FALSE |
Cause ndb_restore to direct its output to
stdout
. Often used together with one or
more of --tab
,
--fields-enclosed-by
,
--fields-optionally-enclosed-by
,
--fields-terminated-by
,
--hex
, and
--append
.
TEXT
and
BLOB
column values are always
truncated. In NDB 7.3.7 and earlier, such values are
truncated to the first 240 bytes in the output; in NDB 7.3.8
and later, they are truncated to 256 bytes. (Bug #14571512,
Bug #65467) This cannot currently be overridden when using
--print-data
.
Command-Line Format | --print-log |
---|---|
Type | Boolean |
Default Value | FALSE |
Cause ndb_restore to output its log to
stdout
.
Command-Line Format | --print-meta |
---|---|
Type | Boolean |
Default Value | FALSE |
Print all metadata to stdout
.
Command-Line Format | --progress-frequency=# |
---|---|
Type | Numeric |
Default Value | 0 |
Minimum Value | 0 |
Maximum Value | 65535 |
Print a status report each N
seconds while the restore is in progress. 0 (the default)
causes no status reports to be printed. The maximum is
65535.
Command-Line Format | --promote-attributes |
---|
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 17.4.1.9.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.
Prior to NDB 7.3.3, conversions between character data types
and TEXT
or BLOB
were
not handled correctly (Bug #17325051).
Prior to NDB 7.3.7, demotion of
TEXT
to
TINYTEXT
was not handled
correctly (Bug #18875137).
When converting between character data types and
TEXT
or BLOB
, only
conversions between character types
(CHAR
and
VARCHAR
) and binary types
(BINARY
and
VARBINARY
) can be performed
at the same time. For example, you cannot promote an
INT
column to
BIGINT
while promoting a
VARCHAR
column to TEXT
in the same invocation of ndb_restore.
Converting between TEXT
columns using different character sets is not supported.
Beginning with NDB 7.3.7, it is expressly disallowed (Bug
#18875137).
When performing conversions of character or binary types to
TEXT
or BLOB
with
ndb_restore, you may notice that it
creates and uses one or more staging tables named
.
These tables are not needed afterwards, and are normally
deleted by ndb_restore following a
successful restoration.
table_name
$STnode_id
Command-Line Format | --rebuild-indexes |
---|
Enable multithreaded rebuilding of the ordered indexes while
restoring a native NDB
backup. The number
of threads used for building ordered indexes by
ndb_restore with this option is
controlled by the
BuildIndexThreads
data node configuration parameter and the number of LDMs.
It is necessary to use this option only for the first run of
ndb_restore; this causes all ordered
indexes to be rebuilt without using
--rebuild-indexes
again when restoring
subsequent nodes. You should use this option prior to
inserting new rows into the database; otherwise, it is
possible for a row to be inserted that later causes a unique
constraint violation when trying to rebuild the indexes.
Building of ordered indices is parallelized with the number
of LDMs by default. Offline index builds performed during
node and system restarts can be made faster using the
BuildIndexThreads
data node configuration parameter; this parameter has no
effect on dropping and rebuilding of indexes by
ndb_restore, which is performed online.
Rebuilding of unique indexes uses disk write bandwidth for
redo logging and local checkpointing. An insufficient amount
of this bandwith can lead to redo buffer overload or log
overload errors. In such cases you can run
ndb_restore
--rebuild-indexes
again; the process
resumes at the point where the error occurred. You can also
do this when you have encountered temporary errors. You can
repeat execution of ndb_restore
--rebuild-indexes
indefinitely; you may be
able to stop such errors by reducing the value of
--parallelism
. If the
problem is insufficient space, you can increase the size of
the redo log
(FragmentLogFileSize
node configuration parameter), or you can increase the speed
at which LCPs are performed
(MaxDiskWriteSpeed
and related parameters), in order to free space more
quickly.
Command-Line Format | --restore-data |
---|---|
Type | Boolean |
Default Value | FALSE |
Output NDB
table data and logs.
Command-Line Format | --restore-epoch |
---|
Add (or restore) epoch information to the cluster
replication status table. This is useful for starting
replication on an NDB Cluster replica. 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 18.6.9, “NDB Cluster Backups With NDB Cluster Replication”.)
Command-Line Format | --restore-meta |
---|---|
Type | Boolean |
Default Value | FALSE |
This option causes ndb_restore to print
NDB
table metadata.
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 metadata need be done only on a single
data node; this is sufficient to restore it to the entire
cluster.
The cluster should have an empty database when starting to
restore a backup. (In other words, you should start the
data nodes with --initial
prior to performing the restore.)
Command-Line Format | --restore-privilege-tables |
---|---|
Type | Boolean |
Default Value | FALSE (If option is not used) |
ndb_restore does not by default restore distributed MySQL privilege tables. This option causes ndb_restore to restore the privilege tables.
This works only if the privilege tables were converted to
NDB
before the backup was
taken. For more information, see
Section 18.5.12, “Distributed Privileges Using Shared Grant Tables”.
--rewrite-database
=olddb,newdb
Command-Line Format | --rewrite-database=olddb,newdb |
---|---|
Type | String |
Default Value | none |
This option makes it possible to restore to a database
having a different name from that used in the backup. For
example, if a backup is made of a database named
products
, you can restore the data it
contains to a database named inventory
,
use this option as shown here (omitting any other options
that might be required):
shell> ndb_restore --rewrite-database=product,inventory
The option can be employed multiple times in a single
invocation of ndb_restore. Thus it is
possible to restore simultaneously from a database named
db1
to a database named
db2
and from a database named
db3
to one named db4
using --rewrite-database=db1,db2
--rewrite-database=db3,db4
. Other
ndb_restore options may be used between
multiple occurrences of --rewrite-database
.
In the event of conflicts between multiple
--rewrite-database
options, the last
--rewrite-database
option used, reading
from left to right, is the one that takes effect. For
example, if --rewrite-database=db1,db2
--rewrite-database=db1,db3
is used, only
--rewrite-database=db1,db3
is honored, and
--rewrite-database=db1,db2
is ignored. It
is also possible to restore from multiple databases to a
single database, so that --rewrite-database=db1,db3
--rewrite-database=db2,db3
restores all tables and
data from databases db1
and
db2
into database db3
.
When restoring from multiple backup databases into a
single target database using
--rewrite-database
, no check is made for
collisions between table or other object names, and the
order in which rows are restored is not guaranteed. This
means that it is possible in such cases for rows to be
overwritten and updates to be lost.
Command-Line Format | --skip-broken-objects |
---|
This option causes ndb_restore to ignore
corrupt tables while reading a native
NDB
backup, and to continue
restoring any remaining tables (that are not also
corrupted). Currently, the
--skip-broken-objects
option works only in
the case of missing blob parts tables.
Command-Line Format | --skip-table-check |
---|
It is possible to restore data without restoring table metadata. By default when doing this, ndb_restore fails with an error if a mismatch is found between the table data and the table schema; this option overrides that behavior.
Some of the restrictions on mismatches in column definitions
when restoring data using ndb_restore are
relaxed; when one of these types of mismatches is
encountered, ndb_restore does not stop
with an error as it did previously, but rather accepts the
data and inserts it into the target table while issuing a
warning to the user that this is being done. This behavior
occurs whether or not either of the options
--skip-table-check
or
--promote-attributes
is
in use. These differences in column definitions are of the
following types:
Different COLUMN_FORMAT
settings
(FIXED
, DYNAMIC
,
DEFAULT
)
Different STORAGE
settings
(MEMORY
, DISK
)
Different default values
Different distribution key settings
Command-Line Format | --skip-unknown-objects |
---|
This option causes ndb_restore to ignore
any schema objects it does not recognize while reading a
native NDB
backup. This can be
used for restoring a backup made from a cluster running (for
example) NDB 7.4 to a cluster running NDB Cluster 7.3.
Command-Line Format | --tab=dir_name |
---|---|
Type | Directory name |
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.
Command-Line Format | --verbose=# |
---|---|
Type | Numeric |
Default Value | 1 |
Minimum Value | 0 |
Maximum Value | 255 |
Sets the level for the verbosity of the output. The minimum is 0; the maximum is 255. The default value is 1.
Error reporting.
ndb_restore reports both temporary and
permanent errors. In the case of temporary errors, it may able
to recover from them, and reports Restore successful,
but encountered temporary error, please look at
configuration
in such cases.
After using ndb_restore to initialize an
NDB Cluster for use in circular replication, binary logs on
the SQL node acting as the replica are not automatically
created, and you must cause them to be created manually. 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 in NDB Cluster.