content_image/697056.jpg
restored to a column of type INT  or BIGINT . See Replication of Columns Having Different Data Types, for a table of type conversions currently supported by attribute promotion. 

Beginning with NDB 8.0.26, 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 $ST node_id . These tables are not needed afterwards, and are normally deleted by ndb_restore  following a successful restoration. 

• --rebuild-indexes 

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

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 

