Environmental Science:
OS:CentOS 7_ X64
Database: mysql-5.7
MASTER:192.168.119.23
BACKUP:192.168.119.24
VIP:192.168.119.138
The detailed configuration of keepalived + MySQL build process will not be described. Many detailed configuration documents on the Internet can be referred to by ourselves. We go straight to the topic.
Here I mainly share a very strange phenomenon in the keeparavlied + MySQL of the construction company. When server a is the master master, VIP 192.168.119.138 is bound, and 192.168.119.138 3306 ports of Telnet can be pinged normally on local computer a, At this time, it is normal to Ping 192.168.119.138 on server B. However, when telnet 192.168.119.138 3306 fails to find a route, it is normal to check that there is no VIP on server B at this time, but telnet VIP + other ports are normal.
Frequent repeated tests show that when servers a and B are running keepalived at the same time, the server in the backup role cannot telnet 192.168.119.138 3306, but can ping telnet normally after shutting down keepalived on the backup role server.
The problem is still the configuration file, which will keepalived.conf The LVS of the configuration file does not use the debugging algorithm lb_ Algo and forwarding mode LB_ If kind is removed, it is these two items that make the backup server unable to access mysql. The normal configuration file is as follows:
[[email protected] ~]# vi /etc/keepalived/ keepalived.conf
global_ defs {
notification_ email {
[email protected]
}
notification_ email_ from [email protected]
smtp_ server 127.0.0.1
smtp_ connect_ timeout 30
router_ id MYSQL_ Ha ා logo, double main same
}
vrrp_ instance VI_ 1 {
State backup ා backup is set for both
interface eth0
virtual_ router_ The primary and secondary ID is the same
Priority 100 ා priority, backup setting 50
advert_ int 1
Nopreempt ා it does not actively preempt resources. It is only set in the master with high priority, and backup does not need to be set
authentication {
auth_ type PASS
auth_ pass 1111
}
virtual_ ipaddress {
192.168.119.138
}
}
virtual_ server 192.168.0.204 3306 {
delay_ loop 2
#lb_ Algo RR ා LVS algorithm. If we don't use it, we close it
#lb_ Kind Dr ා is the reason for the above phenomenon. If the LVS mode is not turned off, the standby server cannot connect to the main MySQL through VIP
persistence_ Timeout 50 ා the connection of the same IP is assigned to the same real server within 60 seconds
protocol TCP
real_ Server 192.168.119.23 3306
weight 3
notify_ down /usr/local/keepalived/ mysql.sh #When mysq server is down, execute this script to kill keepalived to realize the switch. You can also add other commands or scripts.
TCP_ CHECK {
connect_ Timeout 3 ා connection timeout
Nb_ get_ Retry 3
delay_ before_ Retry 3
}
}
Although the problem has been solved, why is this? I used the same version of MySQL and keepalived to test in RHEL 6.0 x64 environment without this problem. Ask the master to appear to answer.
Keepalived + MySQL backup server can ping via VIP, but telnet VIP + 3306 fails
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.