content_image/851619.jpg
For variable-size table attributes, the data is stored on separate data pages, allocated from DataMemory . Variable-length records use a fixed-size part with an extra overhead of 4 bytes to reference the variable-size part. The variable-size part has 2 bytes overhead plus 2 bytes per attribute. 

As of NDB 8.0.18, the maximum record size is 30000 bytes. Previously, this was 14000 bytes. 

Resources assigned to DataMemory  are used for storing all data and indexes. (Any memory configured as IndexMemory  is automatically added to that used by DataMemory  to form a common resource pool.) 

Currently, NDB Cluster can use a maximum of 512 MB for hash indexes per partition, which means in some cases it is possible to get Table is full  errors in MySQL client applications even when ndb_mgm -e "ALL REPORT MEMORYUSAGE"  shows significant free DataMemory . This can also pose a problem with data node restarts on nodes that are heavily loaded with data. 

You can control the number of partitions per local data manager for a given table by setting the NDB_TABLE  option PARTITION_BALANCE  to one of the values FOR_RA_BY_LDM , FOR_RA_BY_LDM_X_2 , FOR_RA_BY_LDM_X_3 , or FOR_RA_BY_LDM_X_4 , for 1, 2, 3, or 4 partitions per LDM, respectively, when creating the table (see Section 13.1.20.11, “Setting NDB_TABLE Options” ). 

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

## Note 

In previous versions of NDB Cluster it was possible to create extra partitions for NDB Cluster tables and thus have more memory available for hash indexes by using the MAX_ROWS  option for CREATE TABLE . While still supported for backward compatibility, using MAX_ROWS  for this purpose is deprecated; you should use PARTITION_BALANCE  instead. 

You can also use the MinFreePct  configuration parameter to help avoid problems with node restarts. 

The memory space allocated by DataMemory  consists of 32KB pages, which are allocated to table fragments. Each table is normally partitioned into the same number of fragments as there are data nodes in the cluster. Thus, for each node, there are the same number of fragments as are set in NoOfReplicas . 

Once a page has been allocated, it is currently not possible to return it to the pool of free pages, except by deleting the table. (This also means that DataMemory  pages, once allocated to a given table, cannot be used by other tables.) Performing a data node recovery also compresses the partition because all records are inserted into empty partitions from other live nodes. 

The DataMemory  memory space also contains UNDO information: For each update, a copy of the unaltered record is allocated in the DataMemory . There is also a reference to each copy in the ordered table indexes. Unique hash indexes are updated only when the unique index columns are updated, in which case a new entry in the index table is inserted and the old entry is deleted upon commit. For this reason, it is also necessary to allocate enough memory to handle the largest transactions performed by 

