content_image/825394.jpg content_image/825395.jpg content_image/825398.jpg
--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 

<img src='content_image/825394.jpg'>

Output NDB  table data and logs. 

• --restore-epoch , -e 

<img src='content_image/825395.jpg'>

Add (or restore) epoch information to the cluster replication status table. This is useful for starting replication on an NDB Cluster replica. 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 23.6.9, “NDB Cluster Backups With NDB Cluster Replication” .) 

• --restore-meta , -m 

<img src='content_image/825398.jpg'>

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 8.0, when restoring metadata, this is no longer an issue; ndb_restore 

