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 :)
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
