NAME
ndb_restore - restore a MySQL Cluster backup
SYNOPSIS
ndb_restore options
DESCRIPTION
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 backup restoration program ndb_restore. Additional descriptions
follow the table. For options common to all MySQL Cluster programs, see
Section 17.4.2, “Options Common to MySQL Cluster Programs”.
Typical options for this utility are shown here:
ndb_restore [-c connectstring] -n
node_id [-s] [-m] -b backup_id -r --backup_path=/path/to/backup/files [-e]
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.3.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:
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.
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.
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.
-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=.
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; --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.
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 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.
Most of the options available for this program are shown in the
following table:
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|Long Form | Short Form | Description | Default Value |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--backup-id | -b | Backup sequence | None |
| | | ID | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--backup_path | None | Path to backup | None |
|(added in MySQL | | files | |
|5.1.17 and MySQL | | | |
|Cluster | | | |
| NDB | | | |
|6.1.5; | | | |
|previously this | | | |
|was | | | |
| backup_path | | | |
|— see Note in | | | |
|text) | | | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--character-sets-dir | None | Specify the | None |
| | | directory where | |
| | | character set | |
| | | information can | |
| | | be found | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--connect, --connectstring, | -c or -C | Set the | localhost:1186 |
|or | | connectstring in | |
| --ndb-connectstring | | [nodeid=node_id;][host=]host[:port] | |
| | | format | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--core-file | None | Write a core file in the event of an error | TRUE |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--debug | -# | Output debug log | d:t:O,/tmp/ndb_restore.trace |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--dont_ignore_systab_0 | -f | Do not ignore system table during restore — | FALSE |
| | | EXPERIMENTAL; not for production | |
| | | use | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--exclude-databases=db_list | None | Do not restore the indicated database or databases | [N/A] |
| | | (added in MySQL | |
| | | Cluster NDB 6.3.22 and 6.4.3) | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--exclude-missing-columns | None | Ignore any columns present in the backup copy of the | [N/A] |
| | | table that are not | |
| | | present in the table as being | |
| | | restored (added in MySQL | |
| | | Cluster NDB 6.3.26 and 7.0.7) | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--exclude-tables=tbl_list | None | Do not restore the indicated table or tables; each | [N/A] |
| | | table must be | |
| | | specified using | |
| | | database.table | |
| | | format (added in MySQL Cluster NDB | |
| | | 6.3.22 and 6.4.3) | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--help or --usage | -? | Display help message with available options and | [N/A] |
| | | current values, then | |
| | | exit | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--include-databases=db_list | None | Restore only the indicated database or databases | [N/A] |
| | | (added in MySQL Cluster | |
| | | NDB 6.3.22 and 6.4.3) | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--include-tables=tbl_list | None | Restore only the indicated table or tables; each | [N/A] |
| | | table must be specified | |
| | | using | |
| | | database.table | |
| | | format (added in MySQL Cluster NDB | |
| | | 6.3.22 and 6.4.3) | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--ndb-mgmd-host | None | Set the host and port in | None |
| | | host[:port] | |
| | | format for the management server to | |
| | | connect to; this | |
| | | is the same as --connect, | |
| | | --connectstring, or | |
| | | --ndb-connectstring, but without a | |
| | | way to specify the nodeid | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--ndb-nodegroup-map | -z | Specifies a nodegroup map — Syntax: list of | None |
| | | (source_nodegroup, | |
| | | destination_nodegroup) | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--ndb-nodeid | None | Specify a node ID for the ndb_restore process | 0 |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--ndb-optimized-node-selection | None | Optimize selection of nodes for transactions | TRUE |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--ndb-shm | None | Use shared memory connections when available | FALSE |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--no-binlog | None | Do not write anything to mysqld binary logs (added in | FALSE (in other words, write |
| | | MySQL Cluster NDB 6.2.16 and | to binary logs unless |
| | | 6.3.16) | this |
| | | | option is used) |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--no-restore-disk-objects | -d | Do not restore Disk Data objects such as tablespaces | FALSE (in other words, |
| | | and log file groups | restore Disk Data objects |
| | | | unless |
| | | | this option is used) |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--no-upgrade | -u | Do not re-create VARSIZE columns from a MySQL 5.0 | FALSE (in other words, |
| | | Cluster backup as variable-width | re-create |
| | | columns (added in | VARSIZE |
| | | MySQL 5.1.19) | columns from a MySQL 5.0 |
| | | | Cluster |
| | | | backup as variable-width |
| | | | columns unless this |
| | | | option is |
| | | | used) |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--nodeid | -n | Use backup files from node with the specified ID | 0 |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--parallelism | -p | Set from 1 to 1024 parallel transactions to be used | 128 |
| | | during the | |
| | | restoration process | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--print | None | Print metadata, data, and log to stdout | FALSE |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--print_data | None | Print data to stdout | FALSE |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--print_log | None | Print log to stdout | FALSE |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--print_meta | None | Print metadata to stdout | FALSE |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--restore_data | -r | Restore data and logs | FALSE |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--restore_epoch | -e | Restore epoch data into the status table; the row in | FALSE |
| | | the | |
| | | cluster.apply_status having the id | |
| | | 0 is inserted or updated as | |
| | | appropriate — this is convenient | |
| | | when starting | |
| | | up replication on a MySQL Cluster | |
| | | replication slave | |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--restore_meta | -m | Restore table metadata | FALSE |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--skip-table-check | -s | Do not check table schemas (Added in MySQL 5.1.17) | FALSE |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
|--version | -V | Output version information and exit | [N/A] |
+--------------------------------------+------------+-------------------------------------------------------+------------------------------+
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 table:
+--------------------------------+------------+-----------------------------------+---------------+
|Long Form | Short Form | Description | Default Value |
+--------------------------------+------------+-----------------------------------+---------------+
|--tab | -T | Creates | None |
| | | dumpfiles, one | |
| | | per table, each | |
| | | named | |
| | | tbl_name.txt. | |
| | | Takes | |
| | | as its argument | |
| | | the path to the | |
| | | directory | |
| | | where | |
| | | the files should | |
| | | be saved | |
| | | (required; use | |
| | | . | |
| | | for the current | |
| | | directory). | |
+--------------------------------+------------+-----------------------------------+---------------+
|--fields-enclosed-by | None | String used to enclose all column | None |
| | | values | |
+--------------------------------+------------+-----------------------------------+---------------+
|--fields-optionally-enclosed-by | None | String used to enclose column | None |
| | | values containing character data | |
| | | (such as | |
| | | CHAR, | |
| | | VARCHAR, | |
| | | BINARY, | |
| | | TEXT, or | |
| | | ENUM) | |
+--------------------------------+------------+-----------------------------------+---------------+
|--fields-terminated-by | None | String used to separate column | \t (tab |
| | | values | character) |
+--------------------------------+------------+-----------------------------------+---------------+
|--hex | None | Use hex format for binary values | [N/A] |
+--------------------------------+------------+-----------------------------------+---------------+
|--lines-terminated-by | None | String used to terminate each | \n (linefeed |
| | | line | character) |
+--------------------------------+------------+-----------------------------------+---------------+
|--append | None | When used with --tab, causes the | [N/A] |
| | | data | |
| | | to be | |
| | | appended to existing files of the | |
| | | same name | |
+--------------------------------+------------+-----------------------------------+---------------+
Note
If a table has no explicit primary key, then the output generated
when using the --print 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_restore other_options db_name_1 [db_name_2[, db_name_3][, ...] | tbl_name_1[, tbl_name_2][, ...]]
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
Beginning with MySQL Cluster NDB 6.3.22 and 6.4.3, you can (and should)
use instead the options --include-databases and --include-tables 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. 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
(For the sake of clarity and brevity, we have omitted other, possibly
required, options in the example just shown.) When --include-databases,
--include-tables, or both are used, only those databases or tables
specified are restored; all other databases and tables are ignored by
ndb_restore.
Also beginning with MySQL Cluster NDB 6.3.22 and 6.4.3, it is possible
to exclude from being restored one or more databases, tables, or both
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. 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.)
You should not use --include-databases or --include-tables together
with --exclude-databases or --exclude-tables, since --include-databases
and --include-tables exclude all databases and tables not explicitly
named. Similarly, --exclude-databases and --exclude-tables include all
databases and tables not listed in the arguments to these options.
Beginning with MySQL Cluster NDB 6.3.26 and MySQL Cluster NDB 7.0.7, it
is also possible 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.
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. 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.
COPYRIGHT
Copyright 2007-2008 MySQL AB, 2009 Sun Microsystems, Inc.
This documentation is free software; you can redistribute it and/or
modify it only under the terms of the GNU General Public License as
published by the Free Software Foundation; version 2 of the License.
This documentation is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License along
with the program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA or see
http://www.gnu.org/licenses/.
SEE ALSO
For more information, please refer to the MySQL Reference Manual, which
may already be installed locally and which is also available online at
http://dev.mysql.com/doc/.
AUTHOR
Sun Microsystems, Inc. (http://www.mysql.com/).