• Multiple transporters.  NDB 8.0.20 introduces support for multiple transporters to handle node-to- node communication between pairs of data nodes. This facilitates higher rates of update operations for each node group in the cluster, and helps avoid constraints imposed by system or other limitations on inter-node communications using a single socket. 

By default, NDB  now uses a number of transporters based on the number of local data management (LDM) threads or the number of transaction coordinator (TC) threads, whichever is greater. By default, the number of transporters is equal to half of this number. While the default should perform well for most workloads, it is possible to adjust the number of transporters employed by each node group by setting the NodeGroupTransporters  data node configuration parameter (also introduced in NDB 8.0.20), up a maximum of the greater of the number of LDM threads or the number of TC threads. Setting it to 0 causes the number of transporters to be the same as the number of LDM threads. 

• ndb_restore: primary key schema changes.  NDB 8.0.21 (and later) supports different primary key definitions for source and target tables when restoring an NDB  native backup with ndb_restore  when it is run with the --allow-pk-changes  option. Both increasing and decreasing the number of columns making up the original primary key are supported. 

When the primary key is extended with an additional column or columns, any columns added must be defined as NOT NULL , and no values in any such columns may be changed during the time that the backup is being taken. Because some applications set all column values in a row when updating it, whether or not all values are actually changed, this can cause a restore operation to fail even if no values in the column to be added to the primary key have changed. You can override this behavior using the --ignore-extended-pk-updates  option also added in NDB 8.0.21; in this case, you must ensure that no such values are changed. 

A column can be removed from the table’s primary key whether or not this column remains part of the table. 

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

• Merging backups with ndb_restore.  In some cases, it may be desirable to consolidate data originally stored in different instances of NDB Cluster (all using the same schema) into a single target NDB Cluster. This is now supported when using backups created in the ndb_mgm  client (see Section 23.5.8.2, “Using The NDB Cluster Management Client to Create a Backup” ) and restoring them with ndb_restore , using the --remap-column  option added in NDB 8.0.21 along with --restore- data  (and possibly additional compatible options as needed or desired). --remap-column  can be employed to handle cases in which primary and unique key values are overlapping between source clusters, and it is necessary that they do not overlap in the target cluster, as well as to preserve other relationships between tables such as foreign keys. 

--remap-column  takes as its argument a string having the format db . tbl . col : fn : args , where db , tbl , and col  are, respectively, the names of the database, table, and column, fn  is the name of a remapping function, and args  is one or more arguments to fn . There is no default value. Only offset  is supported as the function name, with args  as the integer offset to be applied to the value of the column when inserting it into the target table from the backup. This column must be one of INT  or 

