List:Cluster« Previous MessageNext Message »
From:Mikael Ronström Date:August 25 2004 10:08am
Subject:Re: Doubts about cluster features
View as plain text  

2004-08-24 kl. 18.42 skrev Devananda:

> Crouch, Luke H. wrote:
>> you may specify any number (up to hundreds, I believe) of API nodes, 
>> which are typical mysql servers configured to use the cluster as 
>> their storage engine rather than their typical data files. in this 
>> way, you can have multiple mysql servers accepting connections and 
>> processing queries and all will have the same data. so you may 
>> round-robin or use some other method to balance your client 
>> connections to these servers and not worry about data consistency - 
>> it is handled by the cluster storage engine.
> I believe there is currently a limit of 64 nodes in the cluster, 
> counting each DB node, each API node, and the MGM node. I remember 
> reading that this was an arbitrary compile time limit, but I haven't 
> heard how to change it. Please correct me if I'm wrong, or if anyone 
> knows how to change this I would be quite interested :)

The following things needs to be changed (never tested so testing might 
uncover more things needing change, never had access to bigger cluster 
72 CPU's so the limit of 64 has never been a problem.

Currently there are two max's in the limitations.
The first is a limitation on the number of DB nodes.
The second is a limit on the total number of MGM, API and DB nodes in 
the system.

This limit is set in the file
with the lines

  * Note that actual value = MAX_NODES - 1,
  *  since NodeId = 0 can not be used
#define MAX_NDB_NODES 49
#define MAX_NODES     64

As mentioned here node id 0 is not used so 48 DB nodes and 63 nodes in 
total is the maximum.

If anybody updates these parameters ensure that MAX_NODES is a multiple 
of 32 (96, 128, 160, 192 and so forth).

DB nodes can as seen here only use node id 1 - 48.

Updating these parameters will make it possible to have more nodes. It 
will have some negative impact on performance
since there are lots of loops from 1 to MAX_NODES and MAX_NDB_NODES. 
When this will be noticable I have no
idea. Actually using more nodes will also slow down select calls since 
there are more connections to loop over to
fetch input. So having more nodes will certainly have some cost 
attached to it but unknown how big or small.

In addition if MAX_NODES is set to more than 128 it is necessary to 
also update another constant.
with the line.

const int MAX_NTRANSPORTERS = 128;

Rgrds Mikael
In a few days yet another place needs to be updated that is not yet 
pushed to the public 4.1 clone and this is in the file
#define MAX_NODES_STRING "63"
where 63 = MAX_NODES - 1

> To help try and explain how the cluster functions, as it is quite 
> different from traditional mysql or oracle databases,  I'll attempt a 
> little ASCII art (wish me luck!)
>                    -- any number of normal database clients --
>       -- it makes no difference which API node a client connects to --
>        [ Apache/php clients ]                     [ any other normal 
> mysql clients ]
>                             |                                          
>               |
>                          /  |  \                                       
>            /  |  \
> [ API nodes]  @ @  @         @      @            @     @  @  @
> -- here's part of the magic of the cluster, all of the api nodes are 
> connected to all of the DB nodes automatically --
> -- thus load balancing is performed internally across all the DB nodes 
> --
> -- it's up to you (the dba/programmer) to load balance across the API 
> nodes though --
> [ DB nodes ]         D                 D                   D           
>     D
>                            (D)              (D)                 (D)    
>        (D)               [ NoOfReplicas = 2, 3 or 4 ] -- this gives 
> you a built in failsafe
>                                  if one of the DB nodes crashes, it's 
> replica automatically and
>                                  almost seamlessly picks up its load
>                                                    \  |  /
>                                            [ MGM node ]
> -- the MGM node must be aware of all API and DB nodes, since it is the 
> central management process (does lots of stuff) --
> I hope that helps :)
> Devananda
> Neopets, Inc
> -- 
> MySQL Cluster Mailing List
> For list archives:
> To unsubscribe:    
Mikael Ronström, Senior Software Architect


Doubts about cluster featuresRoberto Melo Cavalcante24 Aug
RE: Doubts about cluster featuresLuke H. Crouch24 Aug
  • Re: Doubts about cluster featuresDevananda24 Aug
    • Re: Doubts about cluster featuresMikael Ronström25 Aug