MySQL Forums
Forum List  »  NDB clusters

cluster heartbeat configuration problem
Posted by: ryan lwf
Date: April 14, 2005 05:42AM

Hi,

I've installed mysql cluster on 3 nodes, ie 2 storage nodes and one management node. The storage nodes have 2 NICs in each of them. Network configuration is as follows:

Storage node 1 (ndbd and mysqld resides here)
eth0 IP = 192.168.8.1 /24
eth1 IP = 10.0.0.1 /24
default gw = 192.168.8.100 /24

Storage node 2 (ndbd and 2nd mysqld resides here)
eth0 IP = 192.168.8.2 /24
eth1 IP = 10.0.0.2 /24
default gw = 192.168.8.100 /24

Mgm node (ndb_mgmd)
eth0 IP = 192.168.8.3 /24
default gw = 192.168.8.100 /24

I have connected 10.0.0.1 <-> 10.0.0.2 with a crossover cable, and 192.168.8.1, 192.168.8.2 and 192.168.8.3 to a switch that is also connected to our internal LAN clients (in 192.168.8.0 network) so that our internal webserver can connect to the cluster. The idea is to have the "10.0.0.0" IPs as the heartbeat LAN, while the 192.168.8.1 and .2 are interfaces to listen to sql requests from internal LAN clients.

However, the cluster has injected UDP packets (i believe is heartbeat packets ?) into the 192.168.8.0 network, causing our internal LAN to a drag. UDP packets info are as follows :

Source IP = 192.168.8.1 / 192.168.8.2 (coming from both alternately)
Source port = 3706
Destination IP = 239.0.0.10
Destination port = 3706

If i issue a ping to 239.0.0.10 from mgm node (192.168.8.3), i got replies from 192.168.8.1 interleaving with 192.168.8.2 replies, all from the same ping instance.

How do I configure the cluster to use the 10.0.0.0 network for keepalive / heartbeat use, so as not to flood the 192.168.8.0 network and it's clients with UDP packets, while still able to connect to the cluster from the internal LAN ?

Thanks !

Options: ReplyQuote


Subject
Views
Written By
Posted
cluster heartbeat configuration problem
5641
April 14, 2005 05:42AM


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.