Skip navigation links
MySQL 5.0 Reference Manual :: 17 MySQL Cluster :: 17.4 MySQL Cluster Programs :: 17.4.15 ndb_restore — Restore a MySQL Cluster Backup
17.4.16 ndb_select_all — Print Rows from an NDB Table »
Section Navigation      [Toggle]

17.4.15. 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.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.21, “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.0.40    
--backup_path=path Path to backup files directory 5.0.38    
--backupid=# Restore from the backup with the given ID      
--connect Same as connectstring      
--restore_data Restore table data and logs into NDB Cluster using the NDB API      
--dont_ignore_systab_0 Do not ignore system table during restore. Experimental only; not for production use      
--fields-enclosed-by=char Fields are enclosed with the indicated character 5.0.40    
--fields-optionally-enclosed-by Fields are optionally enclosed with the indicated character 5.0.40    
--fields-terminated-by=char Fields are terminated by the indicated character 5.0.40    
--hex Print binary types in hexadecimal format 5.0.40    
--lines-terminated-by=char Lines are terminated by the indicated character 5.0.40    
--restore_meta Restore metadata to NDB Cluster using the NDB API      
--no-restore-disk-objects Do not restore Disk Data objects such as tablespaces and log file groups      
--nodeid=# Back up files from node with this ID      
--parallelism=# Number of parallel transactions during restoration of data      
--print Print metadata, data and log to stdout (equivalent to --print_meta --print_data --print_log)      
--print_data Print data to stdout      
--print_log Print to stdout      
--print_metadata Print metadata to stdout      
--restore_epoch Restore epoch info into the status table. Convenient on a MySQL Cluster replication slave for starting replication. The row in mysql.ndb_apply_status with id 0 will be updated/inserted.      
--tab=path Creates a tab-separated .txt file for each table in the given path 5.0.40    
--verbose=# Control level of verbosity in output      

Typical options for this utility are shown here: 

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

The -c option is used to specify a connectstring which tells ndb_restore where to locate the cluster management server. (See Section 17.3.2.2, “The MySQL Cluster Connectstring”, for information on connectstrings.) If this option is not used, then ndb_restore attempts to connect to a management server on localhost:1186. This utility acts as a cluster API node, and so requires a free connection “slot” to connect to the cluster management server. This means that there must be at least one [api] or [mysqld] section that can be used by it in the cluster config.ini file. It is a good idea to keep at least one empty [api] or [mysqld] section in config.ini that is not being used for a MySQL server or other application for this reason (see Section 17.3.2.6, “Defining SQL and Other API Nodes in a MySQL Cluster”).

You can verify that ndb_restore is connected to the cluster by using the SHOW command in the ndb_mgm management client. You can also accomplish this from a system shell, as shown here: 

shell> ndb_mgm -e "SHOW"

-n is used to specify the node ID of the data node on which the backups were taken.

The first time you run the ndb_restore restoration program, you also need to restore the metadata. In other words, you must re-create the database tables — this can be done by running it with the -m option. Note that the cluster should have an empty database when starting to restore a backup. (In other words, you should start ndbd with --initial prior to performing the restore.)

The -b option is used to specify the ID or sequence number of the backup, and is the same number shown by the management client in the Backup 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.

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.0.38, the path to the backup directory was specified as shown here, with backup_path= being optional: 

[backup_path=]/path/to/backup/files

Beginning with MySQL 5.0.38, this syntax changed to --backup_path=/path/to/backup/files, to conform more closely with options used by other MySQL programs; --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.0 Upgrade and Downgrade Compatibility”, 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 5.0.45 to a cluster running MySQL Cluster 5.0.41, you must use a copy of ndb_restore from the 5.0.45 distribution.

For more rapid restoration, the data may be restored in parallel, provided that there is a sufficient number of cluster connections available. That is, when restoring to multiple nodes in parallel, you must have an [api] or [mysqld] section in the cluster config.ini file available for each concurrent ndb_restore process. However, the data files must always be applied before the logs.

This option causes ndb_restore to print its output to stdout. Beginning with MySQL 5.0.40, several additional options are available for use with the --print_data option in generating data dumps, either to stdout, or to a file. These are similar to some of the options used with mysqldump, and are shown in the following list:

  • --tab, -T

    Version Introduced 5.0.40
    Command-Line Format --tab=path

    This option causes --print_data to create dump files, one per table, each named tbl_name.txt. It requires as its argument the path to the directory where the files should be saved; use . for the current directory.

  • --fields-enclosed-by=string

    Version Introduced 5.0.40
    Command-Line Format --fields-enclosed-by=char
      Permitted Values
    Type string
    Default

    Each column values are enclosed by the string passed to this option (regardless of data type; see next item).

  • --fields-optionally-enclosed-by=string

    Version Introduced 5.0.40
    Command-Line Format --fields-optionally-enclosed-by
      Permitted Values
    Type string
    Default

    The string passed to this option is used to enclose column values containing character data (such as CHAR, VARCHAR, BINARY, TEXT, or ENUM).

  • --fields-terminated-by=string

    Version Introduced 5.0.40
    Command-Line Format --fields-terminated-by=char
      Permitted Values
    Type string
    Default \t (tab)

    The string passed to this option is used to separate column values. The default value is a tab character (\t).

  • --hex

    Version Introduced 5.0.40
    Command-Line Format --hex

    If this option is used, all binary values are output in hexadecimal format.

  • --fields-terminated-by=string

    Version Introduced 5.0.40
    Command-Line Format --fields-terminated-by=char
      Permitted Values
    Type string
    Default \t (tab)

    This option specifies the string used to end each line of output. The default is a linefeed character (\n).

  • --append

    Version Introduced 5.0.40
    Command-Line Format --append

    When used with the --tab and --print_data options, this causes the data to be appended to any existing files having the same names.

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.

Beginning with MySQL 5.0.40, it is possible to restore selected databases, or to restore selected tables from a given database using the syntax shown here: 

ndb_restore other_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

Error reporting.  ndb_restore reports both temporary and permanent errors. In the case of temporary errors, it may able to recover from them. Beginning with MySQL 5.0.29, it reports Restore successful, but encountered temporary error, please look at configuration in such cases.