邪门的Received lower prio advert, forcing new election

场景:配置了keepalived服务的主机由于修改了virtual_router_id后,重启动keepalived服务成功后,出现了两个主机上均存在虚拟IP192.168.0.200的现象。


排错手段:通过检查配置文件,修改priority级别和advert_int的值,均无法修改上述现象导致的错误,唯一能在配置keepalived的一方机器的日志中一直不停的刷如下的日志信息

Feb 19 15:17:01 redis-163 Keepalived_vrrp[4204]: VRRP_Instance(VI_1) Sending gratuitous ARPs on em1 for 192.168.0.200

Feb 19 15:17:11 redis-163 Keepalived_vrrp[4204]: VRRP_Instance(VI_1) Received lower prio advert, forcing new election


3. 最后在排错过程中注意到了一个小细节:

如下是A主机显示的IP信息

 em1: mtu 1500 qdisc mq state UP qlen 1000
    link/ether 90:b1:1c:4b:6c:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.200/32 scope global em1
    inet6 fe80::92b1:1cff:fe4b:6c7e/64 scope link 
       valid_lft forever preferred_lft forever


 bond0: mtu 1500 qdisc noqueue state UP 
    link/ether f0:1f:af:d1:35:05 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.152/24 brd 192.168.0.255 scope global bond0

如下是B主机显示的IP信息

em1: mtu 1500 qdisc mq state UP qlen 1000
    link/ether 90:b1:1c:4b:6c:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.163/24 brd 192.168.0.255 scope global em1
    inet 192.168.0.200/32 scope global em1
    inet6 fe80::92b1:1cff:fe4b:6c7e/64 scope link 
       valid_lft forever preferred_lft forever

到此,细心的读者可能发现了问题的所在。

原因就是由于前段时间对A主机的两个网卡做了绑定,将em1网卡的地址绑定到了bond0之上,所以直接修改配置文件中的em1网卡为bond0网口后,果断重新启动keepalived服务,问题迎刃而解。


体会:运维真是个细致活!

你可能感兴趣的:(mysql)