"Mysql+keepalived" keepalived the become master and the same virtual ipaddr

Premise: MySQL dual master +keepalived to achieve high availability of MySQL.

Environment:

master:172.16.3.5 tidb-node1slave:172.16.3.7 tidb-node3vip:172.16.3.100

Problem: Master opens and enters backup state, then check script detects success, enters Master state, then obtains VIP on master, and then opens keepalived on slvae. is also first into backup state, according to normal logic, in the master broadcast when the slave obtained in the VRRP this group has already existed a master, so slave should continue to keep backup state, but backup The state successfully enters the master state in the check script, and also obtains the VIP.

Configuration information for Master's keepalived:

vrrp_script vs_mysql_82 {  #定义检测脚本     script  "/usr/local/python/bin/ python /etc/keepalived/checkmysql.py -h 172.16.3.5 -p 3306 "     interval 60  #脚本执行的间隔时间}vrrp_instance vi_82 {    state backup    #初始均为BACKUP  state    nopreempt      #设置为不争抢状态, That is, after the master is downgraded to fault, the old master is backup after recovery, not the upgrade to master.    interface eth0  #绑定的网卡      virtual_router_id 172   #route  id; Grouping, the same group is divided into groups      priority 100  #权重     advert_int 5   #keepalived通信的间隔      authentication {        auth_type PASS         auth_pass 1111    }     track_script {       vs_mysql_82  #检测脚本     }    virtual_ ipaddress {        172.16.3.100        }}

    keepalived configuration information for slave:

vrrp_script vs_mysql_82 {    script  "/usr/local/python/bin/python /etc /keepalived/checkmysql.py -h 172.16.3.7 -p 3306 "    interval 60} Vrrp_instance vi_82 {    state backup    nopreempt     interface eth0    virtual_router_id 172     priority 90    advert_int 5    authentication  {        auth_type PASS         auth_pass 1111    }    track_script {        vs_mysql_82    }    virtual_ ipaddress {        172.16.3.100    }}

In this case, my first consideration is the splitting of the brain, but it is possible for us to ping each other. And the local execution of IP addr show in master and Slave is as follows:

Master

[[email protected] ~]# ip addr show1: lo: <loopback,up,lower_up>  mtu 65536 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    inet6 ::1/128 scope host        valid_lft forever preferred_lft forever2: eth0: <broadcast, multicast,up,lower_up> mtu 1500 qdisc mq state up qlen 1000     link/ether 00:0c:29:20:ce:b4 brd ff:ff:ff:ff:ff:ff     inet 172.16.3.5/22 brd 172.16.3.255 scope global eth0     INET&NBSP;172.16.3.100/32&NBSP;SCOPE&NBSP;GLOBAL&NBSP;ETH0&NBSP;&NBSP;&NBSP;&NBSP;INET6&NBSP;FE80::20C:29FF: fe20:ceb4/64 scope link       valid_lft forever preferred_lft forever 

    Slave:

[[Email protected] keepalived]# ip addr show1: lo: <loopback,up,lower_up > mtu 65536 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    inet6 ::1/128 scope host        valid_lft forever preferred_lft forever2: eth0: <broadcast, multicast,up,lower_up> mtu 1500 qdisc mq state up qlen 1000     link/ether 00:0c:29:20:ce:b4 brd ff:ff:ff:ff:ff:ff     inet 172.16.3.5/22 brd 172.16.3.255 scope global eth0     INET&NBSP;172.16.3.100/32&NBSP;SCOPE&NBSP;GLOBAL&NBSP;ETH0&NBSP;&NBSP;&NBSP;&NBSP;INET6&NBSP;FE80::20C:29FF: Fe20:ceb4/64 scope lInk       valid_lft forever preferred_lft forever 

Then link MySQL to execute select @ @hostname

[[email protected] ~]# mysql -urpl -h172.16.3.100 -p -p3306enter  password:welcome to the mysql monitor.  commands end with ;  or \g.your mysql connection id is 10server version: 5.7.17-log  mysql community server  (GPL) copyright  (c)  2000, 2016, oracle and/or  its affiliates. all rights reserved. oracle is a registered trademark of oracle corporation and/or  Itsaffiliates. other names may be trademarks of their respectiveowners . type  ' help; '  or  ' \h '  for help. Type  ' \c '  to clear the current input  statement. [Email protected] 16:12:  [(none)]> select @ @hostname; +------------+| @@ hostname |+------------+| tidb-node3 |+------------+1 row in set  (0.00 sec) 

Then continue to verify:

1. Open execution in master and slave respectively

Tcpdump-i eth0 Host 172.16.3.100-VVVV

2. Turn off keepalived on slave

/etc/init.d/keepalived stop

3. Perform on any non-master and non-slave machine

Ping 172.16.3.100

4. This time in the master display:

[[email protected] keepalived]# tcpdump  -i eth0 host 172.16.3.100  -vvvvtcpdump: listening on eth0, link-type EN10MB  (Ethernet),  capture  size 65535 bytes15:28:11.968811 IP  (tos 0x0, ttl 64, id  57379, offset 0, flags [df], proto icmp  (1),  length 84)      172.16.3.15 > 172.16.3.100: icmp echo request, id 2057 , seq 54, length 6415:28:12.968815 ip  (Tos 0x0, ttl 64, id  57380, offset 0, flags [DF], proto ICMP  (1),  length 84)     172.16.3.15 > 172.16.3.100: icmp echo request, id  2057, seq 55, length 6415:28:13.968840 IP  (tos 0x0, ttl 64,  id 57381, offset 0, flags [df], proto icmp  (1),  length 84)      172.16.3.15 > 172.16.3.100: icmp echo request, id 2057, seq 56 , length 6415:28:14.968870 ip  (tos 0x0, ttl 64, id 57382,  offset 0, flags [df], proto icmp  (1),  length 84)      172.16.3.15 > 172.16.3.100: icmp echo request, id 2057, seq  57, length 6415:28:15.968872 IP  (tos 0x0, ttl 64, id 57383,  offset 0, flags [DF], proto ICMP  (1),  length 84)

5. Restart keepalived in slave

/etc/init.d/keepalived start

6. Shown on master:

15:28:42.097462 arp, ethernet  (len 6), ipv4  (len 4), Request  who-has 172.16.3.100  (broadcast)  tell 172.16.3.100, length 4615:28:42.097693  ARP, Ethernet  (len 6), ipv4  (len 4), request who-has  172.16.3.100  (broadcast)  tell 172.16.3.100, length 4615:28:42.097706 ARP,  ethernet  (len 6), ipv4  (len 4), request who-has 172.16.3.100  ( Broadcast)  tell 172.16.3.100, length 4615:28:42.097711 ARP, Ethernet  (len  6), ipv4  (len 4), request who-has 172.16.3.100  (Broadcast)  tell  172.16.3.100, length 4615:28:42.097715 ARP, Ethernet  (len 6),  ipv4   (LEN 4), request who-has 172.16.3.100  (broadcast)  tell 172.16.3.100,  length 4615:28:47.098555 ARP, Ethernet  (len 6), ipv4  (len 4), request who-has  172.16.3.100  (broadcast)  tell 172.16.3.100, length 4615:28:47.098773 ARP,  ethernet  (len 6), ipv4  (len 4), request who-has 172.16.3.100  ( Broadcast)  tell 172.16.3.100, length 4615:28:47.098783 ARP, Ethernet  (len  6), ipv4  (len 4), request who-has 172.16.3.100  (Broadcast)  tell  172.16.3.100, length 4615:28:47.098786 ARP, Ethernet  (len 6),  ipv4   (LEN 4), request who-has 172.16.3.100  (broadcast)  tell 172.16.3.100,  length 4615:28:47.098789 ARP, Ethernet  (len 6), ipv4  (len 4),  Request who-has 172.16.3.100  (broadcast)  tell 172.16.3.100, length 46

7. Shown above slave:

[[email protected] keepalived]# tcpdump  -i eth0 host 172.16.3.100  -vvvvvtcpdump: listening on eth0, link-type EN10MB  (Ethernet),  capture size 65535 bytes15:28:42.102540 arp, ethernet  (len 6),  IPv4   (LEN 4), request who-has 172.16.3.100  (broadcast)  tell 172.16.3.100,  length 2815:28:42.102614 ARP, Ethernet  (len 6), ipv4  (len 4),  Request who-has 172.16.3.100  (broadcast)  tell 172.16.3.100, length  2815:28:42.102620 arp, ethernet  (len 6), ipv4  (len 4), Request  who-has 172.16.3.100  (broadcast)  tell 172.16.3.100, length 2815:28:42.102625  ARP, Ethernet  (len 6), ipv4  (len 4), request who-has  172.16.3.100  (broadcast)  TELL&Nbsp;172.16.3.100, length 2815:28:42.102636 arp, ethernet  (len 6),  IPv4   (LEN 4), request who-has 172.16.3.100  (broadcast)  tell 172.16.3.100,  length 2815:28:42.974138 IP  (tos 0x0, ttl 64, id 57410,  offset 0, flags [df], proto icmp  (1),  length 84)      172.16.3.15 > 172.16.3.100: icmp echo request, id 2057, seq  85, length 6415:28:42.974268 IP  (tos 0x0, ttl 64, id 41230,  offset 0, flags [none], proto ICMP  (1),  length 84)      172.16.3.100 > 172.16.3.15: ICMP echo reply, id 2057,  seq 85, length 6415:28:43.974149 ip  (tos 0x0, ttl 64, id  57411, offset 0, flags [df], proto icmp  (1),  length 84)     172.16.3.15  > 172.16.3.100: icmp echo request, id 2057, seq 86, length  64

According to the information shown above can be clearly obtained slave is already preempted VIP, although in the master can be IP addr show can see the VIP, but this VIP has not been able to provide services, can not provide communications to the outside.

Then can get the conclusion that the master and slave between the keepalived can not communicate, slave can not communicate with master, so it will preempt VIP, then the problem is how to get two people can not communicate the reason:

-Check your firewall to ensure packets aren ' t being caught-check your networking to ensure EM1 are the same network on Bo Th machines

After Google a few, found that two people can not communicate the cause of the two, one is because the firewall blocked the two people's communication, the other is the binding network card name error. The second reason can be ruled out, then there is only the first reason, checked, found that the firewall is really open, only the opening of the 22,80,3306 port; After shutting down the two firewalls, keepalived can work properly.

Keepalived Communication is the VRRP protocol. Not the 22,80,3306 port.

"Mysql+keepalived" keepalived the become master and the same virtual ipaddr