[lvs-users] Mysql cluster ldirector IP Can't connect to MySQL

Bacterie eu_rau at yahoo.com
Fri Apr 16 10:27:30 BST 2010


Hello,

Yes, the http://www.howtoforge.com/loadbalanced_mysql_cluster_debian
is the correct link of the tutorial.

I have configured the lo:0 interfaces with the loadbalancer ip as described in page 7.

on node sql1 i have

ip a s lo:0
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet 192.168.201.100/32 scope global lo:0

on node sql2

ip a s lo:0
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet 192.168.201.100/32 scope global lo:0

I have added another host to the VPN network with the IP 192.168.201.14.

>From it, issuing arping gives off the following:

arping 192.168.201.100
ARPING 192.168.201.100
42 bytes from fe:ff:ff:ff:ff:ff (192.168.201.100): index=0 time=1.205 msec
42 bytes from fe:ff:ff:ff:ff:ff (192.168.201.100): index=1 time=1.467 msec
42 bytes from fe:ff:ff:ff:ff:ff (192.168.201.100): index=2 time=1.460 msec
42 bytes from fe:ff:ff:ff:ff:ff (192.168.201.100): index=3 time=1.481 msec

I also ran tcpdump on the load balancer host and i have noticed a strange thing.

When i do tcpdump on the tun0 interface, i get the chatter between the management node and the sql nodes but no traffic directed to the VIP.

 tcpdump -i tun0 port 3306
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode              
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes            

09:21:26.929772 IP ip-192-168-201-1.ec2.internal.57553 > ip-192-168-201-6.ec2.internal.mysql: S 3517636247:3517636247(0) win 5840 <mss 1460,sackOK,timestamp 13004102 0,nop,wscale 7>
09:21:26.935957 IP ip-192-168-201-6.ec2.internal.mysql > ip-192-168-201-1.ec2.internal.57553: S 1616136901:1616136901(0) ack 3517636248 win 5792 <mss 1366,sackOK,timestamp 171829194 13004102,nop,wscale 7>                                                                                                                                                                                    
09:21:26.935975 IP ip-192-168-201-1.ec2.internal.57553 > ip-192-168-201-6.ec2.internal.mysql: . ack 1 win 46 <nop,nop,timestamp 13004103 171829194>                                             
09:21:26.936123 IP ip-192-168-201-1.ec2.internal.57553 > ip-192-168-201-6.ec2.internal.mysql: F 1:1(0) ack 1 win 46 <nop,nop,timestamp 13004103 171829194>                                      
09:21:26.936480 IP ip-192-168-201-1.ec2.internal.34946 > ip-192-168-201-10.ec2.internal.mysql: S 3505041773:3505041773(0) win 5840 <mss 1460,sackOK,timestamp 13004103 0,nop,wscale 7>          
09:21:26.936710 IP ip-192-168-201-6.ec2.internal.mysql > ip-192-168-201-1.ec2.internal.57553: P 1:128(127) ack 1 win 46 <nop,nop,timestamp 171829199 13004103>                                  
09:21:26.936723 IP ip-192-168-201-1.ec2.internal.57553 > ip-192-168-201-6.ec2.internal.mysql: R 3517636248:3517636248(0) win 0                                                                  
09:21:26.937079 IP ip-192-168-201-6.ec2.internal.mysql > ip-192-168-201-1.ec2.internal.57553: F 128:128(0) ack 1 win 46 <nop,nop,timestamp 171829199 13004103>  


On the other hand, if i run tcpdump on the lo interface of the loadbalancer and from another session on the loadbalancer run a "telnet 192.168.201.100 3306" i get:

tcpdump -i lo port 3306
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
09:22:08.367299 IP ip-192-168-201-100.ec2.internal.43644 > ip-192-168-201-100.ec2.internal.mysql: S 3556049393:3556049393(0) win 32792 <mss 16396,sackOK,timestamp 13014460 0,nop,wscale 7>
09:22:08.369408 IP ip-192-168-201-100.ec2.internal.mysql > ip-192-168-201-100.ec2.internal.43644: R 0:0(0) ack 3556049394 win 0

So the traffic appears to be directed at lo instead of tun0.

Thanks.







--- On Thu, 4/15/10, Bacterie <eu_rau at yahoo.com> wrote:

From: Bacterie <eu_rau at yahoo.com>
Subject: [lvs-users] Mysql cluster ldirector IP Can't connect to MySQL
To: lvs-users at linuxvirtualserver.org
Date: Thursday, April 15, 2010, 8:17 PM

Hello,



First, let me thank you for the great work that you are doing.

 

I'm trying to set up a Mysql Cluster over AWS instances, but due to the
limitations of Amazon(single ip /instance) i cannot use a virtual IP.

So, i decided to setup a VPN network first so i can have all the IP that i need.



I set up the VPN, all works fine regarding it.



I followed the instructions in http://www.howtoforge.com/loadbalanc...cluster_debian in order to set up the cluster.



I used debian lenny for the setup.



The following IP addresses are used:

192.168.201.1 -load balancer

192.168.201.6 -sql1

192.168.201.10-sql2

192.168.201.100- Virtual IP



On the load balacer node (only one, which is also the OpenVPN server ) i have the following:



ha.cf

 
    Quote:
    
    
        
            
                logfacility        local0

bcast        tun0

mcast tun0 225.0.0.1 694 1 0

auto_failback off

node        <name provided by uname -n for this amazon instance>

node        loadb2

respawn hacluster /usr/lib/heartbeat/ipfail

apiauth ipfail gid=haclient uid=hacluster
            
        
    
    
haresources


    Quote:
    
    
        
            
                <name provided by uname -n for this amazon instance>      \

        ldirectord::ldirectord.cf \

        LVSSyncDaemonSwap::master \

        IPaddr2::192.168.201.100/24/tun0/192.168.201.255



            
        
    
    
ldirectord.cf


    Quote:
    
    
        
            
                # Global Directives

checktimeout=10

checkinterval=2

autoreload=no

logfile="local0"

quiescent=yes



virtual = 192.168.201.100:3306

        service = mysql

        real = 192.168.201.6:3306 gate

        real = 192.168.201.10:3306 gate

        checktype = negotiate

        login = "ldirector"

        passwd = "ldirectorpassword121"

        database = "ldirectordb"

        request = "SELECT * FROM connectioncheck"

        scheduler = wrr



            
        
    
    
A few checks reveal:



ip addr sh tun0


    Quote:
    
    
        
            
                3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100

    link/[65534]

    inet 192.168.201.1 peer 192.168.201.2/32 scope global tun0

    inet 192.168.201.100/24 brd 192.168.201.255 scope global tun0
            
        
    
    
ipvsadm -L -n


    Quote:
    
    
        
            
                IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn

TCP  192.168.201.100:3306 wrr

  -> 192.168.201.6:3306           Route   1      0          0

  -> 192.168.201.10:3306          Route   1      0          0
            
        
    
    
/etc/ha.d/resource.d/LVSSyncDaemonSwap master status

master running

(ipvs_syncmaster pid: 1474)



ldirectord ldirectord.cf status

ldirectord for /etc/ha.d/ldirectord.cf is running with pid: 1391



However, when i try to connect to the virtual ip i get the following


    Quote:
    
    
        
            
                mysql -h 192.168.201.100 -u ldirector -p

Enter password:

ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.201.100' (111)
            
        
    
    
What am i doing wrong? Is The fact that i'm running it over VPN?

Thanks,

Catalin
        


      
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users at LinuxVirtualServer.org
Send requests to lvs-users-request at LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users



      


More information about the lvs-users mailing list