MySQL Cluster - Table is full [Error 1114] while still creating tables I am trying to forward engineer a MySQL Workbench model with about 100 tables to a development single-node cluster and, while creating the 51th table, I end up getting a "1114 table is full" error, which is somewhat curious because there isn't any data inside those tables yet.

I suspected the problem had to be related to the memory allocation of hash indexes, so I have tried to create that table without any constraints or indexes and adding them later, not surprisingly finding that the error came out after trying to add any of the indexes, but getting this incoherent memory usage report:

~$ /usr/local/mysql/bin/ndb_mgm -e "ALL REPORT MEMORYUSAGE"
Connected to Management Server at: localhost:1186
Node 1: Data usage is 0%(13 32K pages of total 16000)
Node 1: Index usage is 0%(71 8K pages of total 32032)


I assume I must be missing something but I still can't figure out what it is. This is my config.ini file:

[NDB_MGMD DEFAULT]
Portnumber=1186

[NDB_MGMD]
NodeId=49
HostName=192.168.122.1
DataDir=/var/lib/MySQL_Cluster/49/
Portnumber=1186

[TCP DEFAULT]
SendBufferMemory=2M
ReceiveBufferMemory=2M

[NDBD DEFAULT]
BackupMaxWriteSize=1M
BackupDataBufferSize=16M
BackupLogBufferSize=4M
BackupMemory=20M
BackupReportFrequency=10
MemReportFrequency=30
LogLevelStartup=15
LogLevelShutdown=15
LogLevelCheckpoint=8
LogLevelNodeRestart=15
DataMemory=500M
IndexMemory=250M
MaxNoOfTables=4096
MaxNoOfTriggers=3500
NoOfReplicas=1
StringMemory=25
DiskPageBufferMemory=64M
SharedGlobalMemory=20M
LongMessageBuffer=32M
MaxNoOfConcurrentTransactions=16384
BatchSizePerLocalScan=512
FragmentLogFileSize=64M
NoOfFragmentLogFiles=16
RedoBuffer=32M
MaxNoOfExecutionThreads=2
StopOnError=false
LockPagesInMainMemory=1
TimeBetweenEpochsTimeout=32000
TimeBetweenWatchdogCheckInitial=60000
TransactionInactiveTimeout=60000
HeartbeatIntervalDbDb=15000
HeartbeatIntervalDbApi=15000

[NDBD]
NodeId=1
HostName=192.168.122.1
DataDir=/var/lib/MySQL_Cluster/1/

[MYSQLD DEFAULT]

[MYSQLD]
NodeId=53
HostName=192.168.122.1

[API]
NodeId=50
HostName=192.168.122.1


Any ideas?
After reading deeper the manual, storing the model in an InnoDB engine and running ndb_size.pl I have been able to find that these parameters (which had their default values) were in fact too low:

    MaxNoOfOrderedIndexes
    MaxNoOfUniqueHashIndexes
    MaxNoOfAttributes