Bug #47793 MaxNoOfTables and MaxNoOfUniqueHashIndexes not strictly enforced in cluster
Submitted: 2 Oct 2009 12:58 Modified: 2 Oct 2009 13:01
Reporter: Hartmut Holzgraefe Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version:mysql-5.1-telco-6.2 OS:Any
Assigned to: CPU Architecture:Any
Tags: mysql-ndb-6.2.15, mysql-ndb-7.0.7

[2 Oct 2009 12:58] Hartmut Holzgraefe
Description:
MaxNoOfTables and MaxNoOfUniqueHashIndexes settings don't seem to be strictly enforced in MySQL Cluster, instead they seem to define the lower bound. Creating a higher number of tables or unique hash indexes than defined in the parameters may or may not be possible depending on other settings.

How to repeat:
default 2 node / 2 replica setup with 

  MaxNoOfTables         can actually create   error code
   
        10                      99               707
        20                     104               707
        30                     109               707
        40                     114               707
   128 (default)               128               136
       150                     128               136

   so the acual max no of user table seems to be more like

       MAX( MaxNoOfTables, 94 + MaxNoOfTables/2 ) 

   here

when using the default MaxNoOfTables=128 and modifying
MaxNoOfOrderedIndexes:

  MaxNoOfOrderedIndexes  can actually create   error code
        128 (default)          128                136
        150                    150                136
        200                    195                707
        250                    245                708 (was actually hitting MaxNoOf Attributes here and didn't bother to raise it)

when trying different values of MaxNoOfUniqueHashIndexes and a
table with one hash index besides the primary key:

  MaxNoOf...   can actually create    error code
  64(default)         104                707
  74                  109                707
  84                  112                707
 128                  127                707
 256                  128                136

Suggested fix:
Either change the behavior so that MaxNoOf... setting act as a strict upper limit for the configured resource or document the current behavior that depending on circumstances it may actually be possible to create more than the defined number of tables or hash indexes ...
[29 Jun 2011 8:57] Jon Stephens
See also BUG#61684