MySQL Forums
Forum List  »  NDB clusters

Where do the SELECT's go? (network distribution..)
Posted by: Marten van Wezel
Date: May 14, 2006 10:50AM

What happens (network-wise) during SELECT's when using ndbcluster tables?

Assume a NDB setup:
1 machine containing the management node
2 machines both containing 1 data node and 1 SQL node.

Now I understand network traffic will occur when doing any write actions into the database, all data nodes neet to be updated, but what happens with selects?

More specifically: As said, I plan to run the two SQL node on the same boxes as one of the data nodes. Can I make the 'local' data node be 'primary' for the SQL node on the same box, and therefore reduce/eliminate the amount of needed network traffic to execute simple selects? Or is NDB 'RAID-ish' in nature and draws parts of the needed data off various boxes? If all data is present locally (and presumably it is, since HA requires a box to have all data in case the other box falls over..), then it would be very nice if it would be fetched from localhost.

Reasons of course being performance, but also network bandwidth cost. My machines are not in the same (physical) location so I pay for every byte.

Can this 'preference' be set somehow? Is it automatic? Or is there some other flaw in my reasoning? The end goal is that with this setup I have 2 machines that both can be 'the site' and if the main server crashes, the backup server is just one DNS change away from being operational.....

If indeed we 'always' need the network for queries, are there other ways to improve this performance? Will setting cache sizes on the SQL node's mysqld to astronomical heights improve things? eAccellerator? memcached?



Edited 3 time(s). Last edit at 05/15/2006 05:46AM by Marten van Wezel.

Options: ReplyQuote


Subject
Views
Written By
Posted
Where do the SELECT's go? (network distribution..)
1652
May 14, 2006 10:50AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.