25.5.23 ndb_restore — Restore an NDB Cluster Backup (original) (raw)

25.5.23 ndb_restore — Restore an NDB Cluster Backup

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.

ndb_restore must be executed once for each of the backup files that were created by theSTART BACKUP command used to create the backup (seeSection 25.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.

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

ALTER TABLE tbl ALTER INDEX idx INVISIBLE;  

This causes MySQL to ignore the index idx on table tbl. SeePrimary Keys and Indexes, for more information, as well as Section 10.3.12, “Invisible Indexes”.

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

--include-databases=db1 --exclude-tables=db1.t1  

However, reversing the order of the options just given simply causes all tables from databasedb1 to be restored (includingdb1.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 matchesdb1 or any tables indb1:

--exclude-tables=db1.t1 --include-databases=db1  
$> 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:

[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 theBLOB table (recall thatNDB 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 ofndb_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 throughslice-id=_`N`_-1.
Example. Assume that you want to restore a backup namedBACKUP-1, found in the default directory/var/lib/mysql-cluster/BACKUP/BACKUP-3 on the node file system on each data node, to a cluster with four data nodes having the node IDs 1, 2, 3, and 4. To perform this operation using five slices, execute the sets of commands shown in the following list:

  1. Restore the cluster metadata usingndb_restore as shown here:
$> ndb_restore -b 1 -n 1 -m --disable-indexes --backup-path=/home/ndbuser/backups  
  1. Restore the cluster data to the data nodes invokingndb_restore as shown here:
$> ndb_restore -b 1 -n 1 -r --num-slices=5 --slice-id=0 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 1 -r --num-slices=5 --slice-id=1 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 1 -r --num-slices=5 --slice-id=2 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 1 -r --num-slices=5 --slice-id=3 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 1 -r --num-slices=5 --slice-id=4 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 2 -r --num-slices=5 --slice-id=0 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 2 -r --num-slices=5 --slice-id=1 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 2 -r --num-slices=5 --slice-id=2 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 2 -r --num-slices=5 --slice-id=3 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 2 -r --num-slices=5 --slice-id=4 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 3 -r --num-slices=5 --slice-id=0 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 3 -r --num-slices=5 --slice-id=1 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 3 -r --num-slices=5 --slice-id=2 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 3 -r --num-slices=5 --slice-id=3 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 3 -r --num-slices=5 --slice-id=4 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 4 -r --num-slices=5 --slice-id=0 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 4 -r --num-slices=5 --slice-id=1 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 4 -r --num-slices=5 --slice-id=2 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 4 -r --num-slices=5 --slice-id=3 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
$> ndb_restore -b 1 -n 4 -r --num-slices=5 --slice-id=4 --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
All of the commands just shown in this step can be executed in parallel, provided there are enough slots for connections to the cluster (see the description for the [\--backup-path](mysql-cluster-programs-ndb-restore.html#option%5Fndb%5Frestore%5Fbackup-path) option).  
  1. Restore indexes as usual, as shown here:
$> ndb_restore -b 1 -n 1 --rebuild-indexes --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  
  1. Finally, restore the epoch, using the command shown here:
$> ndb_restore -b 1 -n 1 --restore-epoch --backup-path=/var/lib/mysql-cluster/BACKUP/BACKUP-1  

You should use slicing to restore the cluster data only; it is not necessary to employ--num-slices or--slice-id when restoring the metadata, indexes, or epoch information. If either or both of these options are used with thendb_restore options controlling restoration of these, the program ignores them.
The effects of using the--parallelism option on the speed of restoration are independent of those produced by slicing or parallel restoration using multiple instances of ndb_restore (--parallelism specifies the number of parallel transactions executed by a_single_ ndb_restore thread), but it can be used together with either or both of these. You should be aware that increasing--parallelism causesndb_restore to impose a greater load on the cluster; if the system can handle this, restoration should complete even more quickly.
The value of --num-slices is not directly dependent on values relating to hardware such as number of CPUs or CPU cores, amount of RAM, and so forth, nor does it depend on the number of LDMs.
It is possible to employ different values for this option on different data nodes as part of the same restoration; doing so should not in and of itself produce any ill effects.

$> 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 usingSHOW CREATE TABLE; thendb_desc tool; andMAX(),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.

$> 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 nameddb1 to a database nameddb2 and from a database nameddb3 to one named db4 using --rewrite-database=db1,db2 --rewrite-database=db3,db4. Otherndb_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 anddb2 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.

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.

The -c option is used to specify a connection string which tells ndb_restore where to locate the cluster management server (seeSection 25.4.3.3, “NDB Cluster Connection Strings”). If this option is not used, then ndb_restore attempts to connect to a management server onlocalhost: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 clusterconfig.ini file. It is a good idea to keep at least one empty [api] or[mysqld] section inconfig.ini that is not being used for a MySQL server or other application for this reason (seeSection 25.4.3.7, “Defining SQL and Other API Nodes in an NDB Cluster”).

ndb_restore can decrypt an encrypted backup using --decrypt and--backup-password. Both options must be specified to perform decryption. See the documentation for the START BACKUP management client command for information on creating encrypted backups.

You can verify that ndb_restore is connected to the cluster by using theSHOW command in thendb_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 aSHOW TABLES statement on that SQL node before running START REPLICA. This is a known issue in NDB Cluster.