17.4.19 ndb_restore — Restore a MySQL Cluster Backup

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.

Note

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.25, “Options Common to MySQL Cluster Programs — Options Common to MySQL Cluster Programs”.

Table 17.23 ndb_restore Options and Variables: MySQL 5.1, MySQL Cluster NDB 6.3-7.1

FormatDescriptionAdded / Removed

--connect,

-c

Alias for --connectstring.

All MySQL 5.1 based releases

--nodeid=#,

-n

Back up files from node with this ID

All MySQL 5.1 based releases

--backupid=#,

-b

Restore from the backup with the given ID

All MySQL 5.1 based releases

--restore_data,

-r

Restore table data and logs into NDB Cluster using the NDB API

All MySQL 5.1 based releases

--restore_meta,

-m

Restore metadata to NDB Cluster using the NDB API

All MySQL 5.1 based releases

--no-upgrade,

-u

Do not upgrade array type for varsize attributes which do not already resize VAR data, and do not change column attributes

ADDED: 5.1.19

--promote-attributes,

-A

Allow attributes to be promoted when restoring data from backup

ADDED: NDB 6.3.8

--preserve-trailing-spaces,

-P

Allow preservation of trailing spaces (including padding) when promoting fixed-width string types to variable-width types

ADDED: NDB 6.3.8

--no-restore-disk-objects,

-d

Do not restore objects relating to Disk Data

ADDED: 5.1.6

--restore_epoch,

-e

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.

All MySQL 5.1 based releases

--skip-table-check,

-s

Skip table structure check during restoring of data

ADDED: 5.1.17

--parallelism=#,

-p

Number of parallel transactions to use while restoring data

All MySQL 5.1 based releases

--print

Print metadata, data and log to stdout (equivalent to --print_meta --print_data --print_log)

All MySQL 5.1 based releases

--print_meta

Print metadata to stdout

All MySQL 5.1 based releases

--print_data

Print data to stdout

All MySQL 5.1 based releases

--print_log

Print to stdout

All MySQL 5.1 based releases

--backup_path=path

Path to backup files directory

ADDED: 5.1.17, NDB 6.1.5

--dont_ignore_systab_0,

-f

Do not ignore system table during restore. Experimental only; not for production use

All MySQL 5.1 based releases

--ndb-nodegroup-map=map,

-z

Nodegroup map for NDBCLUSTER storage engine. Syntax: list of (source_nodegroup, destination_nodegroup)

All MySQL 5.1 based releases

--fields-enclosed-by=char

Fields are enclosed with the indicated character

ADDED: 5.1.18

--fields-terminated-by=char

Fields are terminated by the indicated character

ADDED: 5.1.18

--fields-optionally-enclosed-by

Fields are optionally enclosed with the indicated character

ADDED: 5.1.18

--lines-terminated-by=char

Lines are terminated by the indicated character

ADDED: 5.1.18

--hex

Print binary types in hexadecimal format

ADDED: 5.1.18

--tab=path,

-T

Creates a tab-separated .txt file for each table in the given path

ADDED: 5.1.18

--append

Append data to a tab-delimited file

ADDED: 5.1.18

--progress-frequency=#

Print status of restoration each given number of seconds

All MySQL 5.1 based releases

--no-binlog

If a mysqld is connected and using binary logging, do not log the restored data

ADDED: NDB 6.2.16, NDB 6.3.16

--verbose=#

Level of verbosity in output

All MySQL 5.1 based releases

--include-databases=db-list

List of one or more databases to restore (excludes those not named)

ADDED: NDB 6.3.22, NDB 6.4.3

--exclude-databases=db-list

List of one or more databases to exclude (includes those not named)

ADDED: NDB 6.3.22, 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

ADDED: NDB 6.3.22, NDB 6.4.3

--exclude-tables=table-list

List of one or more tables to exclude (includes those in the same database that are not named); each table reference must include the database name

ADDED: NDB 6.3.22, 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.

ADDED: NDB 6.3.26, NDB 7.0.7

--disable-indexes

Causes indexes from a backup to be ignored; may decrease time needed to restore data.

ADDED: NDB 6.3.31, NDB 7.0.11, NDB 7.1.2

--rebuild-indexes

Causes multi-threaded rebuilding of ordered indexes found in the backup. Number of threads used is determined by setting BuildIndexThreads parameter.

ADDED: NDB 6.3.31, NDB 7.0.11, NDB 7.1.2

--skip-broken-objects

Causes missing blob tables in the backup file to be ignored.

ADDED: NDB 6.3.40, NDB 7.0.21, NDB 7.1.10

--skip-unknown-objects

Causes schema objects not recognized by ndb_restore to be ignored when restoring a backup made from a newer MySQL Cluster version to an older version.

ADDED: NDB 6.3.34, NDB 7.0.15, NDB 7.1.4

--rewrite-database=olddb,newdb

Restores to a database with a different name than the original

ADDED: NDB 6.3.41, NDB 7.0.22, NDB 7.1.11

--lossy-conversions,

-L

Allow lossy conversions of column values (type demotions or changes in sign) when restoring data from backup

ADDED: NDB 7.1.11

--restore-privilege-tables

Restore MySQL privilege tables that were previously moved to NDB.

ADDED: NDB 7.2.0

--exclude-intermediate-sql-tables[=TRUE|FALSE]

If TRUE (the default), do not restore any intermediate tables (having names prefixed with '#sql-') that were left over from copying ALTER TABLE operations.

ADDED: NDB 7.1.31


Typical options for this utility are shown here:

ndb_restore [-c connection_string] -n node_id -b backup_id \
      [-m] -r --backup_path=/path/to/backup/files

Normally, when restoring from a MySQL Cluster backup, ndb_restore requires at a minimum the --nodeid (short form: -n), --backupid (short form: -b), and --backup_path options.

The -c option is used to specify a connection string which tells ndb_restore where to locate the cluster management server. (See Section 17.3.2.3, “MySQL Cluster Connection Strings”, for information on 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 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 --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.)

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.35, MySQL Cluster NDB 7.0.16, and MySQL Cluster NDB 7.1.5, 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:

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.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:

  1. 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.

  2. 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 MySQL Cluster NDB 7.0.40 and MySQL Cluster NDB 7.1.29, conversions between character data types and TEXT or BLOB were not handled correctly (Bug #17325051).

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.

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 table_name$STnode_id. These tables are not needed afterwards, and are normally deleted by ndb_restore following a successful restoration.

--lossy-conversions, -L

Introduced5.1.51-ndb-7.1.11
Command-Line Format--lossy-conversions
 -L
 Permitted Values
Typeboolean
DefaultFALSE

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 16.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.

This option was added in MySQL Cluster NDB 7.1.11.

The --preserve-trailing-spaces option is also available beginning with MySQL Cluster NDB 6.3.8. This option (short form -R) causes 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.

Note

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 backup_id completed message displayed upon completion of a backup. (See Section 17.5.3.2, “Using The MySQL Cluster Management Client to Create a Backup”.)

Important

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”.)

--restore_data

This option causes ndb_restore to output NDB table data and logs.

--restore_meta

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.

--restore-privilege-tables

ndb_restore does not by default restore distributed MySQL privilege tables (MySQL Cluster NDB 7.2.0 and later). 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 17.5.14, “Distributed MySQL Privileges for MySQL Cluster”.

--backup_path

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=.

Note

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=/path/to/backup/files, to conform more closely with options used by other MySQL programs; --backupid 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.7, “Upgrading and Downgrading MySQL Cluster”, for more information.

Important

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 7.1.8 to a cluster running MySQL Cluster NDB 7.0.16, you must use the ndb_restore that comes with the MySQL Cluster NDB 7.1.8 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.

--no-upgrade

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.

--print_data

The --print_data 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 currently be overridden when using --print_data.

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:

Note

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.

--print_meta

This option causes ndb_restore to print all metadata to stdout.

--print_log

The --print_log option causes ndb_restore to output its log to stdout.

--print

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.

Note

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.

--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.

--ndb-nodegroup-map, -z

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.

--no-binlog

This option prevents any connected SQL nodes from writing data restored by ndb_restore to their binary logs. Available beginning with MySQL Cluster NDB 6.2.16 and MySQL Cluster NDB 6.3.16.

--no-restore-disk-objects, -d

This option stops ndb_restore from restoring any MySQL Cluster Disk Data objects, such as tablespaces and log file groups; see Section 17.5.12, “MySQL Cluster Disk Data Tables”, for more information about these. Added in MySQL 5.1.6.

--parallelism=#, -p

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.

--progress-frequency=N

Print a status report each N seconds while the backup is in progress. 0 (the default) causes no status reports to be printed. The maximum is 65535.

--verbose=#

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.1.18, it is possible to restore only selected databases, or selected tables from a single database, using the syntax shown here:

ndb_restore other_options db_name,[db_name[,...] | tbl_name[,tbl_name][,...]]

In other words, you can specify either of the following to be restored:

--include-databases=db_name[,db_name][,...]

Introduced5.1.32-ndb-6.4.3
Command-Line Format--include-databases=db-list
 Permitted Values
Typestring
Default

--include-tables=db_name.tbl_name[,db_name.tbl_name][,...]

Introduced5.1.32-ndb-6.4.3
Command-Line Format--include-tables=table-list
 Permitted Values
Typestring
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 database.table format) to be restored.

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 UsedResult
--include-databases=db1Only 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.t1Only 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.)

Note

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][,...]

Introduced5.1.32-ndb-6.4.3
Command-Line Format--exclude-databases=db-list
 Permitted Values
Typestring
Default

--exclude-tables=db_name.tbl_name[,db_name.tbl_name][,...]

Introduced5.1.32-ndb-6.4.3
Command-Line Format--exclude-tables=table-list
 Permitted Values
Typestring
Default

Beginning with MySQL Cluster NDB 6.3.22 and MySQL Cluster NDB 6.4.3, it is possible to prevent one or more databases or tables from being restored 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 database.table format) which should not be restored.

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 UsedResult
--exclude-databases=db1All 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.t1All 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.)

Note

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:

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
Note

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)

--exclude-missing-columns

Introduced5.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.

--disable-indexes

Introduced5.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 restoration of indexes during restoration of the data from a native NDB backup. Afterwards, you can restore indexes for all tables at once with multi-threaded building of indexes using --rebuild-indexes, which should be faster than rebuilding indexes concurrently for very large tables.

--rebuild-indexes

Introduced5.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 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.

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.

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 temporarary errors. You can repeat execution of ndb_restore --rebuild-indexes indefinitely; you may be able to stop such errors by reducing the value of DiskCheckpointSpeed to provide additional disk bandwidth to redo logging.

--skip-broken-objects

Introduced5.1.51-ndb-7.1.10
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.

This option was added in MySQL Cluster NDB 6.3.40, MySQL Cluster NDB 7.0.21, and MySQL Cluster NDB 7.1.10.

--skip-unknown-objects

Introduced5.1.44-ndb-7.1.4
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 MySQL Cluster NDB 7.0 to a cluster running MySQL Cluster NDB 6.3.

This option was added in MySQL Cluster NDB 6.3.34, MySQL Cluster NDB 7.0.15, and MySQL Cluster NDB 7.1.4.

--rewrite-database=old_dbname,new_dbname

Introduced5.1.51-ndb-7.1.11
Command-Line Format--rewrite-database=olddb,newdb
 Permitted Values
Typestring
Defaultnone

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.

Important

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.

This option was added in MySQL Cluster NDB 6.3.41, MySQL Cluster NDB 7.0.22, and MySQL Cluster NDB 7.1.11.

--exclude-intermediate-sql-tables[=TRUE|FALSE]

Introduced5.1.73-ndb-7.1.31
Command-Line Format--exclude-intermediate-sql-tables[=TRUE|FALSE]
 Permitted Values
Typeboolean
DefaultTRUE

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 such operations. This option is TRUE by default.

The --exclude-intermediate-sql-tables option was introduced in MySQL Cluster NDB 7.1.31. (Bug #17882305)

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.

Important

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. 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 MySQL Cluster.