Bug #47793 MaxNoOfTables and MaxNoOfUniqueHashIndexes not strictly enforced in cluster
Submitted: 2 Oct 14:58 Modified: 2 Oct 15:01
Reporter: Hartmut Holzgraefe
Status: Verified
Category:Server: Cluster Severity:S3 (Non-critical)
Version:mysql-5.1-telco-6.2 OS:Any
Assigned to: Target Version:
Tags: mysql-ndb-7.0.7, mysql-ndb-6.2.15
Triage: Triaged: D3 (Medium) / R6 (Needs Assessment) / E6 (Needs Assessment)

[2 Oct 14: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
...