NDB_RESTORE(1)

NAME
ndb_restore - restore an NDB Cluster backup

SYNOPSIS

ndb_restore options

DESCRIPTION

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.

    Note

    Beginning with NDB 7.5.15 and 7.6.11, 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 21.6.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.

    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 21.6.6, “NDB Cluster Single User Mode”, for more information.

Options that can be used with ndb_restore are shown in the following table. Additional descriptions follow the table.

Table 21.38. Command-line options used with the program ndb_restore
Format | Description | Added, Deprecated, or Removed
--allow-pk-changes[=0|1] | Allow changes to set of columns making up table's primary key | ADDED: NDB 7.6.14
--append | Append data to tab-delimited file | (Supported in all NDB releases based on MySQL 5.7)
--backup-path=path | Path to backup files directory | (Supported in all NDB releases based on MySQL 5.7)
--backupid=#, -b # | Restore from backup having this ID | (Supported in all NDB releases based on MySQL 5.7)
--character-sets-dir=path | Directory containing character sets | (Supported in all NDB releases based on MySQL 5.7)
--connect=connection_string, -c connection_string | Alias for --connectstring | (Supported in all NDB releases based on MySQL 5.7)
--connect-retries=# | Number of times to retry connection before giving up | (Supported in all NDB releases based on MySQL 5.7)
--connect-retry-delay=# | Number of seconds to wait between attempts to contact management server | (Supported in all NDB releases based on MySQL 5.7)
--connect-string=connection_string, -c connection_string | Same as --ndb-connectstring | (Supported in all NDB releases based on MySQL 5.7)
--core-file | Write core file on error; used in debugging | (Supported in all NDB releases based on MySQL 5.7)
--defaults-extra-file=path | Read given file after global files are read | (Supported in all NDB releases based on MySQL 5.7)
--defaults-file=path | Read default options from given file only | (Supported in all NDB releases based on MySQL 5.7)
--defaults-group-suffix=string | Also read groups with concat(group, suffix) | (Supported in all NDB releases based on MySQL 5.7)
--disable-indexes | Causes indexes from backup to be ignored; may decrease time needed to restore data | (Supported in all NDB releases based on MySQL 5.7)
--dont-ignore-systab-0, -f | Do not ignore system table during restore; experimental only; not for production use | (Supported in all NDB releases based on MySQL 5.7)
--exclude-databases=list | List of one or more databases to exclude (includes those not named) | (Supported in all NDB releases based on MySQL 5.7)
--exclude-intermediate-sql-tables[=TRUE|FALSE] | Do not restore any intermediate tables (having names prefixed with '#sql-') that were left over from copying ALTER TABLE operations; specify FALSE to restore such tables | (Supported in all NDB releases based on MySQL 5.7)
--exclude-missing-columns | Causes columns from backup version of table that are missing from version of table in database to be ignored | (Supported in all NDB releases based on MySQL 5.7)
--exclude-missing-tables | Causes tables from backup that are missing from database to be ignored | (Supported in all NDB releases based on MySQL 5.7)
--exclude-tables=list | 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 NDB releases based on MySQL 5.7)
--fields-enclosed-by=char | Fields are enclosed by this character | (Supported in all NDB releases based on MySQL 5.7)
--fields-optionally-enclosed-by | Fields are optionally enclosed by this character | (Supported in all NDB releases based on MySQL 5.7)
--fields-terminated-by=char | Fields are terminated by this character | (Supported in all NDB releases based on MySQL 5.7)
--help, -? | Display help text and exit | (Supported in all NDB releases based on MySQL 5.7)
--hex | Print binary types in hexadecimal format | (Supported in all NDB releases based on MySQL 5.7)
--ignore-extended-pk-updates[=0|1] | Ignore log entries containing updates to columns now included in extended primary key | ADDED: NDB 7.6.14
--include-databases=list | List of one or more databases to restore (excludes those not named) | (Supported in all NDB releases based on MySQL 5.7)
--include-tables=list | 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 NDB releases based on MySQL 5.7)
--lines-terminated-by=char | Lines are terminated by this character | (Supported in all NDB releases based on MySQL 5.7)
--login-path=path | Read given path from login file | (Supported in all NDB releases based on MySQL 5.7)
--lossy-conversions, -L | Allow lossy conversions of column values (type demotions or changes in sign) when restoring data from backup | (Supported in all NDB releases based on MySQL 5.7)
--no-binlog | If mysqld is connected and using binary logging, do not log restored data | (Supported in all NDB releases based on MySQL 5.7)
--no-defaults | Do not read default options from any option file other than login file | (Supported in all NDB releases based on MySQL 5.7)
--no-restore-disk-objects, -d | Do not restore objects relating to Disk Data | (Supported in all NDB releases based on MySQL 5.7)
--no-upgrade, -u | Do not upgrade array type for varsize attributes which do not already resize VAR data, and do not change column attributes | (Supported in all NDB releases based on MySQL 5.7)
--ndb-connectstring=connection_string, -c connection_string | Set connect string for connecting to ndb_mgmd. Syntax: "[nodeid=id;][host=]hostname[:port]". Overrides entries in NDB_CONNECTSTRING and my.cnf | (Supported in all NDB releases based on MySQL 5.7)
--ndb-mgmd-host=connection_string, -c connection_string | Same as --ndb-connectstring | (Supported in all NDB releases based on MySQL 5.7)
--ndb-nodegroup-map=map, -z | Specify node group map; unused, unsupported | (Supported in all NDB releases based on MySQL 5.7)
--ndb-nodeid=# | Set node ID for this node, overriding any ID set by --ndb-connectstring | (Supported in all NDB releases based on MySQL 5.7)
--ndb-optimized-node-selection | Enable optimizations for selection of nodes for transactions. Enabled by default; use --skip-ndb-optimized-node-selection to disable | (Supported in all NDB releases based on MySQL 5.7)
--nodeid=#, -n # | ID of node where backup was taken | (Supported in all NDB releases based on MySQL 5.7)
--num-slices=# | Number of slices to apply when restoring by slice | ADDED: NDB 7.6.13
--parallelism=#, -p # | Number of parallel transactions to use while restoring data | (Supported in all NDB releases based on MySQL 5.7)
--preserve-trailing-spaces, -P | Allow preservation of trailing spaces (including padding) when promoting fixed-width string types to variable-width types | (Supported in all NDB releases based on MySQL 5.7)
--print | Print metadata, data, and log to stdout (equivalent to --print-meta --print-data --print-log) | (Supported in all NDB releases based on MySQL 5.7)
--print-data | Print data to stdout | (Supported in all NDB releases based on MySQL 5.7)
--print-defaults | Print program argument list and exit | (Supported in all NDB releases based on MySQL 5.7)
--print-log | Print log to stdout | (Supported in all NDB releases based on MySQL 5.7)
--print-meta | Print metadata to stdout | (Supported in all NDB releases based on MySQL 5.7)
--print-sql-log | Write SQL log to stdout | ADDED: NDB 7.5.4
--progress-frequency=# | Print status of restore each given number of seconds | (Supported in all NDB releases based on MySQL 5.7)
--promote-attributes, -A | Allow attributes to be promoted when restoring data from backup | (Supported in all NDB releases based on MySQL 5.7)
--rebuild-indexes | Causes multithreaded rebuilding of ordered indexes found in backup; number of threads used is determined by setting BuildIndexThreads | (Supported in all NDB releases based on MySQL 5.7)
--remap-column=string | Apply offset to value of specified column using indicated function and arguments. Format is [db].[tbl].[col]:[fn]:[args]; see documentation for details | ADDED: NDB 7.6.14
--restore-data, -r | Restore table data and logs into NDB Cluster using NDB API | (Supported in all NDB releases based on MySQL 5.7)
--restore-epoch, -e | 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 NDB releases based on MySQL 5.7)
--restore-meta, -m | Restore metadata to NDB Cluster using NDB API | (Supported in all NDB releases based on MySQL 5.7)
--restore-privilege-tables | Restore MySQL privilege tables that were previously moved to NDB | (Supported in all NDB releases based on MySQL 5.7)
--rewrite-database=string | Restore to differently named database; format is olddb,newdb | (Supported in all NDB releases based on MySQL 5.7)
--skip-broken-objects | Ignore missing blob tables in backup file | (Supported in all NDB releases based on MySQL 5.7)
--skip-table-check, -s | Skip table structure check during restore | (Supported in all NDB releases based on MySQL 5.7)
--skip-unknown-objects | 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 NDB releases based on MySQL 5.7)
--slice-id=# | Slice ID, when restoring by slices | ADDED: NDB 7.6.13
--tab=path, -T path | Creates a tab-separated .txt file for each table in path provided | (Supported in all NDB releases based on MySQL 5.7)
--usage, -? | Display help text and exit; same as --help | (Supported in all NDB releases based on MySQL 5.7)
--verbose=# | Level of verbosity in output | (Supported in all NDB releases based on MySQL 5.7)
--version, -V | Display version information and exit | (Supported in all NDB releases based on MySQL 5.7)

    • --allow-pk-changes
    Command-Line Format | --allow-pk-changes[=0|1]
    Introduced | 5.7.29-ndb-7.6.14
    Type | Integer
    Default Value | 0
    Minimum Value | 0
    Maximum Value | 1

    When this option is set to 1, ndb_restore allows the primary keys in a table definition to differ from that of the same table in the backup. This may be desirable when backing up and restoring between different schema versions with primary key changes on one or more tables, and it appears that performing the restore operation using ndb_restore is simpler or mor efficient than issuing many ALTER TABLE statements after restoring table schemas and data.

    The following changes in primary key definitions are supported by --allow-pk-changes:

        • Extending the primary key: A non-nullable column that exists in the table schema in the backup becomes part of the table's primary key in the database.

            Important
            When extending a table's primary key, any columns which become part of primary key must not be updated while the backup is being taken; any such updates discovered by ndb_restore cause the restore operation to fail, even when no change in value takes place. In some cases, it may be possible to override this behavior using the --ignore-extended-pk-updates option; see the description of this option for more information.

        • Contracting the primary key (1): A column that is already part of the table's primary key in the backup schema is no longer part of the primary key, but remains in the table.

        • Contracting the primary key (2): A column that is already part of the table's primary key in the backup schema is removed from the table entirely.

    These differences can be combined with other schema differences supported by ndb_restore, including changes to blob and text columns requiring the use of staging tables.

    Basic steps in a typical scenario using primary key schema changes are listed here:

        1. Restore table schemas using ndb_restore --restore-meta

        2. Alter schema to that desired, or create it

        3. Back up the desired schema

        4. Run ndb_restore --disable-indexes using the backup from the previous step, to drop indexes and constraints

        5. Run ndb_restore --allow-pk-changes (possibly along with --ignore-extended-pk-updates, --disable-indexes, and possibly other options as needed) to restore all data

        6. Run ndb_restore --rebuild-indexes using the backup made with the desired schema, to rebuild indexes and constraints

    When extending the primary key, it may be necessary for ndb_restore to use a temporary secondary unique index during the restore operation to map from the old primary key to the new one. Such an index is created only when necessary to apply events from the backup log to a table which has an extended primary key. This index is named NDB$RESTORE_PK_MAPPING, and is created on each table requiring it; it can be shared, if necessary, by multiple instances of ndb_restore instances running in parallel. (Running ndb_restore --rebuild-indexes at the end of the restore process causes this index to be dropped.)

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

    • --backup-path=dir_name
    Command-Line Format | --backup-path=path
    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 21.3.7, “Upgrading and Downgrading NDB Cluster”, for more information.

        Important
        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.5.27 to a cluster running NDB Cluster 7.4.37, you must use the ndb_restore that comes with the NDB Cluster 7.5.27 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.

    • --backupid=#, -b
    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 backup_id completed message displayed upon completion of a backup. (See Section 21.6.8.2, “Using The NDB 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 can at best result in restoring the cluster to an inconsistent state, and may fail altogether.

    In NDB 7.5.13 and later, and in NDB 7.6.9 and later, this option is required.

    • --character-sets-dir
    Command-Line Format | --character-sets-dir=path

    Directory containing character sets.

    • --connect, -c
    Command-Line Format | --connect=connection_string
    Type | String
    Default Value | localhost:1186

    Alias for --ndb-connectstring.

    • --connect-retries
    Command-Line Format | --connect-retries=#
    Type | Integer
    Default Value | 12
    Minimum Value | 0
    Maximum Value | 12

    Number of times to retry connection before giving up.

    • --connect-retry-delay
    Command-Line Format | --connect-retry-delay=#
    Type | Integer
    Default Value | 5
    Minimum Value | 0
    Maximum Value | 5

    Number of seconds to wait between attempts to contact management server.

    • --connect-string
    Command-Line Format | --connect-string=connection_string
    Type | String
    Default Value | [none]

    Same as --ndb-connectstring.

    • --core-file
    Command-Line Format | --core-file

    Write core file on error; used in debugging.

    • --defaults-extra-file
    Command-Line Format | --defaults-extra-file=path
    Type | String
    Default Value | [none]

    Read given file after global files are read.

    • --defaults-file
    Command-Line Format | --defaults-file=path
    Type | String
    Default Value | [none]

    Read default options from given file only.

    • --defaults-group-suffix
    Command-Line Format | --defaults-group-suffix=string
    Type | String
    Default Value | [none]

    Also read groups with concat(group, suffix).

    • --disable-indexes
    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.

    Beginning with NDB 7.5.24 and NDB 7.6.20, this option also drops any foreign keys specified in the backup.

    • --dont-ignore-systab-0, -f
    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.

    • --exclude-databases=db-list
    Command-Line Format | --exclude-databases=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]
    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.

    • --exclude-missing-columns
    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.

    • --exclude-missing-tables
    Command-Line Format | --exclude-missing-tables

    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.

    • --exclude-tables=table-list
    Command-Line Format | --exclude-tables=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 21.39. 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:

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

    • --fields-enclosed-by=char
    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).

    • --fields-terminated-by=char
    Command-Line Format | --fields-terminated-by=char
    Type | String
    Default Value | (tab)

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

    • --help
    Command-Line Format | --help

    Display help text and exit.

    • --hex
    Command-Line Format | --hex

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

    • --ignore-extended-pk-updates
    Command-Line Format | --ignore-extended-pk-updates[=0|1]
    Introduced | 5.7.29-ndb-7.6.14
    Type | Integer
    Default Value | 0
    Minimum Value | 0
    Maximum Value | 1

    When using the --allow-pk-changes option, columns which become part of a table's primary key must not be updated while the backup is being taken; such columns should keep the same values from the time values are inserted into them until the rows containing the values are deleted. If ndb_restore encounters updates to these columns when restoring a backup, the restore fails. Because some applications may set values for all columns when updating a row, even when some column values are not changed, the backup may include log events appearing to update columns which are not in fact modified. In such cases you can set --ignore-extended-pk-updates to 1, forcing ndb_restore to ignore such updates.

        Important
        When causing these updates to be ignored, the user is responsible for ensuring that there are no updates to the values of any columns that become part of the primary key.

    For more information, see the description of --allow-pk-changes.

    • --include-databases=db-list
    Command-Line Format | --include-databases=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.

    • --include-tables=table-list
    Command-Line Format | --include-tables=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 21.40. 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):

        $> 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_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

    • --lines-terminated-by=char
    Command-Line Format | --lines-terminated-by=char
    Type | String
    Default Value | (linebreak)

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

    • --login-path
    Command-Line Format | --login-path=path
    Type | String
    Default Value | [none]

    Read given path from login file.

    • --lossy-conversions, -L
    Command-Line Format | --lossy-conversions

    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.10.2, “Replication of Columns Having Different Data Types”, for information about specific type conversions currently supported by attribute demotion.

    Beginning with NDB 7.5.23 and NDB 7.6.19, this option also makes it possible to restore a NULL column as NOT NULL. The column must not contain any NULL entries; otherwise ndb_restore stops with an error.

    ndb_restore reports any truncation of data that it performs during lossy conversions once per attribute and column.

    • --ndb-connectstring
    Command-Line Format | --ndb-connectstring=connection_string
    Type | String
    Default Value | [none]

    Set connect string for connecting to ndb_mgmd. Syntax: "[nodeid=id;][host=]hostname[:port]". Overrides entries in NDB_CONNECTSTRING and my.cnf.

    • --ndb-mgmd-host
    Command-Line Format | --ndb-mgmd-host=connection_string
    Type | String
    Default Value | [none]

    Same as --ndb-connectstring.

    • --ndb-nodegroup-map=map, -z
    Command-Line Format | --ndb-nodegroup-map=map

    Intended for restoring a backup taken from one node group to a different node group, but never completely implemented; unsupported.

    • --ndb-nodeid
    Command-Line Format | --ndb-nodeid=#
    Type | Integer
    Default Value | [none]

    Set node ID for this node, overriding any ID set by --ndb-connectstring.

    • --ndb-optimized-node-selection
    Command-Line Format | --ndb-optimized-node-selection

    Enable optimizations for selection of nodes for transactions. Enabled by default; use --skip-ndb-optimized-node-selection to disable.

    • --no-binlog
    Command-Line Format | --no-binlog

    This option prevents any connected SQL nodes from writing data restored by ndb_restore to their binary logs.

    • --no-defaults
    Command-Line Format | --no-defaults

    Do not read default options from any option file other than login file.

    • --no-restore-disk-objects, -d
    Command-Line Format | --no-restore-disk-objects

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

    • --no-upgrade, -u
    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.

    • --nodeid=#, -n
    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 the section called “Restoring to a different number of data nodes”, for additional information and examples.

    In NDB 7.5.13 and later, and in NDB 7.6.9 and later, this option is required.

    • --num-slices=#
    Command-Line Format | --num-slices=#
    Introduced | 5.7.29-ndb-7.6.13
    Type | Integer
    Default Value | 1
    Minimum Value | 1
    Maximum Value | 1024

    When restoring a backup by slices, this option sets the number of slices into which to divide the backup. This allows multiple instances of ndb_restore to restore disjoint subsets in parallel, potentially reducing the amount of time required to perform the restore operation.

    A slice is a subset of the data in a given backup; that is, it is a set of fragments having the same slice ID, specified using the --slice-id option. The two options must always be used together, and the value set by --slice-id must always be less than the number of slices.

    ndb_restore encounters fragments and assigns each one a fragment counter. When restoring by slices, a slice ID is assigned to each fragment; this slice ID is in the range 0 to 1 less than the number of slices. For a table that is not a BLOB table, the slice to which a given fragment belongs is determined using the formula shown here:

        [slice_ID] = [fragment_counter] % [number_of_slices]

    For a BLOB table, a fragment counter is not used; the fragment number is used instead, along with the ID of the main table for the BLOB table (recall that NDB stores BLOB values in a separate table internally). In this case, the slice ID for a given fragment is calculated as shown here:

        [slice_ID] =
        ([main_table_ID] + [fragment_ID]) % [number_of_slices]

    Thus, restoring by N slices means running N instances of ndb_restore, all with --num-slices=N (along with any other necessary options) and one each with --slice-id=1, --slice-id=2, --slice-id=3, and so on through slice-id=N-1.

    • --parallelism=#, -p
    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.

        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.

    • --print
    Command-Line Format | --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 an NDB Cluster.

    • --print-data
    Command-Line Format | --print-data

    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. Such values are truncated to the first 256 bytes in the output. This cannot currently be overridden when using --print-data.

    • --print-defaults
    Command-Line Format | --print-defaults

    Print program argument list and exit.

    • --print-log
    Command-Line Format | --print-log

    Cause ndb_restore to output its log to stdout.

    • --print-meta
    Command-Line Format | --print-meta

    Print all metadata to stdout.

    • print-sql-log
    Command-Line Format | --print-sql-log
    Introduced | 5.7.16-ndb-7.5.4

    Log SQL statements to stdout. Use the option to enable; normally this behavior is disabled. The option checks before attempting to log whether all the tables being restored have explicitly defined primary keys; queries on a table having only the hidden primary key implemented by NDB cannot be converted to valid SQL.

    This option does not work with tables having BLOB columns.

    The --print-sql-log option was added in NDB 7.5.4. (Bug #13511949)

    • --progress-frequency=N
    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 backup is in progress. 0 (the default) causes no status reports to be printed. The maximum is 65535.

    • --promote-attributes, -A
    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 16.4.1.10.2, “Replication of Columns Having Different Data Types”, for a table of type conversions currently supported by attribute promotion.

    Beginning with NDB 7.5.23 and NDB 7.6.19, this option also makes it possible to restore a NOT NULL column as NULL.

    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.

    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, and is expressly disallowed.

    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.

    • --rebuild-indexes
    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.

    • --remap-column=db.tbl.col:fn:args
    Command-Line Format | --remap-column=string
    Introduced | 5.7.29-ndb-7.6.14
    Type | String
    Default Value | [none]

    When used together with --restore-data, this option applies a function to the value of the indicated column. Values in the argument string are listed here:

        • db: Database name, following any renames performed by --rewrite-database.

        • tbl: Table name.

        • col: Name of the column to be updated. This column must be of type INT or BIGINT. The column can also be but is not required to be UNSIGNED.

        • fn: Function name; currently, the only supported name is offset.

        • args: Arguments supplied to the function. Currently, only a single argument, the size of the offset to be added by the offset function, is supported. Negative values are supported. The size of the argument cannot exceed that of the signed variant of the column's type; for example, if col is an INT column, then the allowed range of the argument passed to the offset function is -2147483648 to 2147483647 (see Section 11.1.2, “Integer Types (Exact Value) - INTEGER, INT, SMALLINT, TINYINT, MEDIUMINT, BIGINT”).

        If applying the offset value to the column would cause an overflow or underflow, the restore operation fails. This could happen, for example, if the column is a BIGINT, and the option attempts to apply an offset value of 8 on a row in which the column value is 4294967291, since 4294967291 + 8 = 4294967299 > 4294967295.

    This option can be useful when you wish to merge data stored in multiple source instances of NDB Cluster (all using the same schema) into a single destination NDB Cluster, using NDB native backup (see Section 21.6.8.2, “Using The NDB Cluster Management Client to Create a Backup”) and ndb_restore to merge the data, where primary and unique key values are overlapping between source clusters, and it is necessary as part of the process to remap these values to ranges that do not overlap. It may also be necessary to preserve other relationships between tables. To fulfill such requirements, it is possible to use the option multiple times in the same invocation of ndb_restore to remap columns of different tables, as shown here:

        $> ndb_restore --restore-data --remap-column=hr.employee.id:offset:1000 \
            --remap-column=hr.manager.id:offset:1000 --remap-column=hr.firstaiders.id:offset:1000

    (Other options not shown here may also be used.)

    --remap-column can also be used to update multiple columns of the same table. Combinations of multiple tables and columns are possible. Different offset values can also be used for different columns of the same table, like this:

        $> ndb_restore --restore-data --remap-column=hr.employee.salary:offset:10000 \
            --remap-column=hr.employee.hours:offset:-10

    When source backups contain duplicate tables which should not be merged, you can handle this by using --exclude-tables, --exclude-databases, or by some other means in your application.

    Information about the structure and other characteristics of tables to be merged can obtained using SHOW CREATE TABLE; the ndb_desc tool; and MAX(), MIN(), LAST_INSERT_ID(), and other MySQL functions.

    Replication of changes from merged to unmerged tables, or from unmerged to merged tables, in separate instances of NDB Cluster is not supported.

    • --restore-data, -r
    Command-Line Format | --restore-data

    Output NDB table data and logs.

    • --restore-epoch, -e
    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 replica cluster. 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 21.7.9, “NDB Cluster Backups With NDB Cluster Replication”.)

    • --restore-meta, -m
    Command-Line Format | --restore-meta

    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.

    In older versions of NDB Cluster, tables whose schemas were restored using this option used the same number of partitions as they did on the original cluster, even if it had a differing number of data nodes from the new cluster. In NDB 7.5.2 and later, when restoring metadata, this is no longer an issue; ndb_restore now uses the default number of partitions for the target cluster, unless the number of local data manager threads is also changed from what it was for data nodes in the original cluster.

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

    • --restore-privilege-tables
    Command-Line Format | --restore-privilege-tables

    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 21.6.12, “Distributed Privileges Using Shared Grant Tables”.

    • --rewrite-database=olddb,newdb
    Command-Line Format | --rewrite-database=string
    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):

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

    • --skip-broken-objects
    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.

    • --skip-table-check, -s
    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

    • --skip-unknown-objects
    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.6 to a cluster running NDB Cluster 7.5.

    • --slice-id=#
    Command-Line Format | --slice-id=#
    Introduced | 5.7.29-ndb-7.6.13
    Type | Integer
    Default Value | 0
    Minimum Value | 0
    Maximum Value | 1023

    When restoring by slices, this is the ID of the slice to restore. This option is always used together with --num-slices, and its value must be always less than that of --num-slices.

    For more information, see the description of the --num-slices elsewhere in this section.

    • --tab=dir_name, -T dir_name
    Command-Line Format | --tab=path
    Type | Directory name

    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.

    • --usage
    Command-Line Format | --usage

    Display help text and exit; same as --help.

    • --verbose=#
    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.

    • --version
    Command-Line Format | --version

    Display version information and exit.

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

    $> ndb_mgm -e "SHOW"

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.

    Important

    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.

  Restoring an NDB Backup to a Different Version of NDB Cluster

The following two sections provide information about restoring a native NDB backup to a different version of NDB Cluster from the version in which the backup was taken.

In addition, you should consult Section 21.3.7, “Upgrading and Downgrading NDB Cluster”, for other issues you may encounter when attempting to restore an NDB backup to a cluster running a different version of the NDB software.

It is also advisable to review What is New in NDB Cluster 8.0[1], as well as Section 2.11.3, “Changes in MySQL 5.7”, for other changes between NDB 8.0 and previous versions of NDB Cluster that may be relevant to your particular circumstances.

Restoring an NDB backup to a previous version of NDB Cluster

    You may encounter issues when restoring a backup taken from a later version of NDB Cluster to a previous one, due to the use of features which do not exist in the earlier version. Some of these issues are listed here:

        • Tables created in NDB 8.0 by default use the utf8mb4_ai_ci character set, which is not available in NDB 7.6 and earlier, and so cannot be read by an ndb_restore binary from one of these earlier versions. In such cases, it is necessary to alter any tables using utf8mb4_ai_ci so that they use a character set supported in the older version prior to performing the backup.

        • Due to changes in how the MySQL Server and NDB handle table metadata, tables created or altered using the included MySQL server binary from NDB 8.0.14 or later cannot be restored using ndb_restore to an earlier version of NDB Cluster. Such tables use .sdi files which are not understood by older versions of mysqld.

        A backup taken in NDB 8.0.14 or later of tables which were created in NDB 8.0.13 or earlier, and which have not been altered since upgrading to NDB 8.0.14 or later, should be restorable to older versions of NDB Cluster.

        Since it is possible to restore metadata and table data separately, you can in such cases restore the table schemas from a dump made using mysqldump, or by executing the necessary CREATE TABLE statements manually, then import only the table data using ndb_restore with the --restore-data option.

        • Encrypted backups created in NDB 8.0.22 and later cannot be restored using ndb_restore from NDB 8.0.21 or earlier.

        • The NDB_STORED_USER privilege is not supported prior to NDB 8.0.18.

        • NDB Cluster 8.0.18 and later supports up to 144 data nodes, while earlier versions support a maximum of only 48 data nodes. See the section called “Restoring to Fewer Nodes Than the Original”, for information with situations in which this incompatibility causes an issue.

Restoring an NDB backup to a later version of NDB Cluster

    In general, it should be possible to restore a backup created using the ndb_mgm client START BACKUP command in an older version of NDB to a newer version, provided that you use the ndb_restore binary that comes with the newer version. (It may be possible to use the older version of ndb_restore, but this is not recommended.) Additional potential issues are listed here:

        • When restoring the metadata from a backup (--restore-meta option), ndb_restore normally attempts to reproduce the captured table schema exactly as it was when the backup was taken.

        Tables created in versions of NDB prior to 8.0.14 use .frm files for their metadata. These files can be read by the mysqld in NDB 8.0.14 and later, which can use the information contained therein to create the .sdi files used by the MySQL data dictionary in later versions.

        • When restoring an older backup to a newer version of NDB, it may not be possible to take advantage of newer features such as hashmap partitioning, greater number of hashmap buckets, read backup, and different partitioning layouts. For this reason, it may be preferable to restore older schemas using mysqldump and the mysql client, which allows NDB to make use of the new schema features.

        • Tables using the old temporal types which did not support fractional seconds (used prior to MySQL 5.6.4 and NDB 7.3.31) cannot be restored to NDB 8.0 using ndb_restore. You can check such tables using CHECK TABLE, and then upgrade them to the newer temporal column format, if necessary, using REPAIR TABLE in the mysql client; this must be done prior to taking the backup. See Preparing Your Installation for Upgrade[2], for more information.

        You also also restore such tables using a dump created with mysqldump.

        • Distributed grant tables created in NDB 7.6 and earlier are not supported in NDB 8.0. Such tables can be restored to an NDB 8.0 cluster, but they have no effect on access control.

  Restoring to a different number of data nodes

It is possible to restore from an NDB backup to a cluster having a different number of data nodes than the original from which the backup was taken. The following two sections discuss, respectively, the cases where the target cluster has a lesser or greater number of data nodes than the source of the backup.

Restoring to Fewer Nodes Than the Original

    You can restore to a cluster having fewer data nodes than the original provided that the larger number of nodes is an even multiple of the smaller number. In the following example, we use a backup taken on a cluster having four data nodes to a cluster having two data nodes.

        1. The management server for the original cluster is on host host10. The original cluster has four data nodes, with the node IDs and host names shown in the following extract from the management server's config.ini file:

            [ndbd]
            NodeId=2
            HostName=host2
            [ndbd]
            NodeId=4
            HostName=host4
            [ndbd]
            NodeId=6
            HostName=host6
            [ndbd]
            NodeId=8
            HostName=host8

        We assume that each data node was originally started with ndbmtd --ndb-connectstring=host10 or the equivalent.

        2. Perform a backup in the normal manner. See Section 21.6.8.2, “Using The NDB Cluster Management Client to Create a Backup”, for information about how to do this.

        3. The files created by the backup on each data node are listed here, where N is the node ID and B is the backup ID.

            • BACKUP-B-0.N.Data

            • BACKUP-B.N.ctl

            • BACKUP-B.N.log

        These files are found under BackupDataDir/BACKUP/BACKUP-B, on each data node. For the rest of this example, we assume that the backup ID is 1.

        Have all of these files available for later copying to the new data nodes (where they can be accessed on the data node's local file system by ndb_restore). It is simplest to copy them all to a single location; we assume that this is what you have done.

        4. The management server for the target cluster is on host host20, and the target has two data nodes, with the node IDs and host names shown, from the management server config.ini file on host20:

            [ndbd]
            NodeId=3
            hostname=host3
            [ndbd]
            NodeId=5
            hostname=host5

        Each of the data node processes on host3 and host5 should be started with ndbmtd -c host20 --initial or the equivalent, so that the new (target) cluster starts with clean data node file systems.

        5. Copy two different sets of two backup files to each of the target data nodes. For this example, copy the backup files from nodes 2 and 4 from the original cluster to node 3 in the target cluster. These files are listed here:

            • BACKUP-1-0.2.Data

            • BACKUP-1.2.ctl

            • BACKUP-1.2.log

            • BACKUP-1-0.4.Data

            • BACKUP-1.4.ctl

            • BACKUP-1.4.log

        Then copy the backup files from nodes 6 and 8 to node 5; these files are shown in the following list:

            • BACKUP-1-0.6.Data

            • BACKUP-1.6.ctl

            • BACKUP-1.6.log

            • BACKUP-1-0.8.Data

            • BACKUP-1.8.ctl

            • BACKUP-1.8.log

        For the remainder of this example, we assume that the respective backup files have been saved to the directory /BACKUP-1 on each of nodes 3 and 5.

        6. On each of the two target data nodes, you must restore from both sets of backups. First, restore the backups from nodes 2 and 4 to node 3 by invoking ndb_restore on host3 as shown here:

            $> ndb_restore -c host20 --nodeid=2 --backupid=1 --restore-data --backup-path=/BACKUP-1
            $> ndb_restore -c host20 --nodeid=4 --backupid=1 --restore-data --backup-path=/BACKUP-1

        Then restore the backups from nodes 6 and 8 to node 5 by invoking ndb_restore on host5, like this:

            $> ndb_restore -c host20 --nodeid=6 --backupid=1 --restore-data --backup-path=/BACKUP-1
            $> ndb_restore -c host20 --nodeid=8 --backupid=1 --restore-data --backup-path=/BACKUP-1

Restoring to More Nodes Than the Original

    The node ID specified for a given ndb_restore command is that of the node in the original backup and not that of the data node to restore it to. When performing a backup using the method described in this section, ndb_restore connects to the management server and obtains a list of data nodes in the cluster the backup is being restored to. The restored data is distributed accordingly, so that the number of nodes in the target cluster does not need to be to be known or calculated when performing the backup.

        Note

        When changing the total number of LCP threads or LQH threads per node group, you should recreate the schema from backup created using mysqldump.

        1. Create the backup of the data. You can do this by invoking the ndb_mgm client START BACKUP command from the system shell, like this:

            $> ndb_mgm -e "START BACKUP 1"

        This assumes that the desired backup ID is 1.

        2. Create a backup of the schema. In NDB 7.5.2 and later, this step is necessary only if the total number of LCP threads or LQH threads per node group is changed.

            $> mysqldump --no-data --routines --events --triggers --databases > myschema.sql

            Important
            Once you have created the NDB native backup using ndb_mgm, you must not make any schema changes before creating the backup of the schema, if you do so.

        3. Copy the backup directory to the new cluster. For example if the backup you want to restore has ID 1 and BackupDataDir = /backups/node_nodeid, then the path to the backup on this node is /backups/node_1/BACKUP/BACKUP-1. Inside this directory there are three files, listed here:

            • BACKUP-1-0.1.Data

            • BACKUP-1.1.ctl

            • BACKUP-1.1.log

        You should copy the entire directory to the new node.

        If you needed to create a schema file, copy this to a location on an SQL node where it can be read by mysqld.

    There is no requirement for the backup to be restored from a specific node or nodes.

    To restore from the backup just created, perform the following steps:

        1. Restore the schema.

            • If you created a separate schema backup file using mysqldump, import this file using the mysql client, similar to what is shown here:

                $> mysql < myschema.sql

            When importing the schema file, you may need to specify the --user and --password options (and possibly others) in addition to what is shown, in order for the mysql client to be able to connect to the MySQL server.

            • If you did not need to create a schema file, you can re-create the schema using ndb_restore --restore-meta (short form -m), similar to what is shown here:

                $> ndb_restore --nodeid=1 --backupid=1 --restore-meta --backup-path=/backups/node_1/BACKUP/BACKUP-1

            ndb_restore must be able to contact the management server; add the --ndb-connectstring option if and as needed to make this possible.

        2. Restore the data. This needs to be done once for each data node in the original cluster, each time using that data node's node ID. Assuming that there were 4 data nodes originally, the set of commands required would look something like this:

            ndb_restore --nodeid=1 --backupid=1 --restore-data --backup-path=/backups/node_1/BACKUP/BACKUP-1 --disable-indexes
            ndb_restore --nodeid=2 --backupid=1 --restore-data --backup-path=/backups/node_2/BACKUP/BACKUP-1 --disable-indexes
            ndb_restore --nodeid=3 --backupid=1 --restore-data --backup-path=/backups/node_3/BACKUP/BACKUP-1 --disable-indexes
            ndb_restore --nodeid=4 --backupid=1 --restore-data --backup-path=/backups/node_4/BACKUP/BACKUP-1 --disable-indexes

        These can be run in parallel.

        Be sure to add the --ndb-connectstring option as needed.

        3. Rebuild the indexes. These were disabled by the --disable-indexes option used in the commands just shown. Recreating the indexes avoids errors due to the restore not being consistent at all points. Rebuilding the indexes can also improve performance in some cases. To rebuild the indexes, execute the following command once, on a single node:

            $> ndb_restore --nodeid=1 --backupid=1 --backup-path=/backups/node_1/BACKUP/BACKUP-1 --rebuild-indexes

        As mentioned previously, you may need to add the --ndb-connectstring option, so that ndb_restore can contact the management server.

COPYRIGHT

Copyright © 1997, 2022, Oracle and/or its affiliates.

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

NOTES

1.  What is New in NDB Cluster 8.0
    https://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-what-is-new.html#mysql-cluster-what-is-new-8-0

2.  Preparing Your Installation for Upgrade
    https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html

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
Oracle Corporation (http://dev.mysql.com/).