Only just seen this mail, sorry if it's already been sorted.
I had the same sort of problems with this kind of set up.
Do you have the following set in /etc/sysctl.conf?
net.ipv4.ip_forward = 1
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.eth0.arp_announce = 2
Then on your box that is the LVS master you should have the VIP as an
additional IP on the eth0 interface (My shared VIP is 10.167.30.76):
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:1a:64:21:e5:71 brd ff:ff:ff:ff:ff:ff
inet 10.167.30.73/25 brd 10.167.30.127 scope global eth0
inet 10.167.30.76/25 brd 10.167.30.127 scope global secondary eth0
inet6 fe80::21a:64ff:fe21:e571/64 scope link
valid_lft forever preferred_lft forever
and on the other box it should only be on the lo interface.
ogg-dvla-01:~ # ip add sh lo
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet 10.167.30.76/32 brd 10.167.30.255 scope global lo:0
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
When the ldirector resource fails over to the other node it should drop
the VIP from eth0 on the master box (the one that does respond to ARPs),
add it to lo and then on the slave box it will add it to eth0 and drop
it from lo.
You have to configure it manually into lo first though (suse config
style):
# Loopback (lo) configuration
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
BROADCAST=127.255.255.255
STARTMODE=onboot
USERCONTROL=no
IPADDR_0=10.167.30.76 # VIP
NETMASK_0=255.255.255.255
NETWORK_0=10.167.30.0
BROADCAST_0=10.167.30.255
LABEL_0='0'
I've got a master-master load-balanced MySQL cluster doing circular
replication working very nicely like this.
Hope this helps.
Darren
> -----Original Message-----
> From: [email protected] [mailto:linux-ha-
> [email protected]] On Behalf Of Terry, Jason
> Sent: 22 May 2009 01:04
> To: '[email protected]'
> Subject: [Linux-HA] MySQL cluster doesn't route
>
> I've recently started to setup a test MySQL cluster in my VMware setup
on
> a windows vista box.
>
> I've set up three Debian Lenny virtual machines.
>
> 1) 10.10.10.108 - this is the box I connect to the cluster with
>
> 2) 10.10.10.98 - MySQL node, heartbeat, ldirectord
>
> 3) 10.10.10.105 - MySQL node, heartbeat, ldirectord
>
> I have heartbeat working, and failing over nicely.
> I have ldirectord starting and stopping nicely with heartbeat... and
> ldirectord even negotiates and connects to MySQL.
>
> ldirector.cf
> # Global Directives
> checktimeout=10
> checkinterval=2
> autoreload=no
> logfile="local0"
> quiescent=yes
>
> virtual = 10.10.10.99:3306
> service = mysql
> real = 10.10.10.105:3306 gate
> real = 10.10.10.98:3306 gate
> checktype = negotiate
> login = "ldirector"
> passwd = "xxxxx"
> database = "test"
> request = "SELECT UserID FROM UserInfo WHERE UserID = 123"
> scheduler = wrr
>
> Both machines however refuse to "Route" traffic to the other...
>
> For example if I have ipvsadm -Ln output of
> TCP 10.10.10.99:3306 wrr
> -> 10.10.10.105:3306 Local 1 0 0
> -> 10.10.10.98:3306 Route 1 0 0
>
> The master has 10.10.10.99 bound on bond0... the slave has it bound on
> loopback
>
> In the example above, the master box successfully makes a connection
to
> all 3 ip addresses.
> In the example above, a third Debian box 10.10.10.108 can connect
> "sometimes", based on which box it connects to.
>
> After research I found that if I disable one to make this output:
> TCP 10.10.10.99:3306 wrr
> -> 10.10.10.105:3306 Local 1 0 0
> Then all MySQL connections from the remote box work fine.
>
> However when I connect using this:
> TCP 10.10.10.99:3306 wrr
> -> 10.10.10.98:3306 Route 1 0 0
> All MySQL connections from the remote box time out.
>
> If I set the master to the other box, then it does the exact same
thing...
> the "Local" works fine but the "Route" fail.
>
> Any ideas on what I'm missing to make the "Route" piece work?
>
> Thanks
> -Jason
> _______________________________________________
> Linux-HA mailing list
> [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
