the backupser log is always print Entering MASTER STATE/Entering BACKUP STATE about keepalived HOT 5 OPEN

There are a number of issues identified here:

1. There is no configuration keyword notify_ - see line notify_ /etc/keepalived/scripts/notify__mysql.sh #set read_only=0
2. Jun 17 20:42:49 oadb02 Keepalived_vrrp[144285]: (VI_1) Entering STATE is strange. It should say what state is being entered, i.e. BACKUP, FAULT or MASTER.
3. I can't see any log entry for entering MASTER state, despite the subject of this issue.
4. You have multiple (VI_1) received an invalid passwd! entries, but these are not consistent. What is happening that is causing the password that is being sent to change?

You haven't stated what version of keepalived you are using. Please provide the output of keepalived -v.

from keepalived.

There are a number of issues identified here:↳

1. There is no configuration keyword notify_ - see line notify_ /etc/keepalived/scripts/notify__mysql.sh #set read_only=0
2. Jun 17 20:42:49 oadb02 Keepalived_vrrp[144285]: (VI_1) Entering STATE is strange. It should say what state is being entered, i.e. BACKUP, FAULT or MASTER.
3. I can't see any log entry for entering MASTER state, despite the subject of this issue.
4. You have multiple (VI_1) received an invalid passwd! entries, but these are not consistent. What is happening that is causing the password that is being sent to change?

You haven't stated what version of keepalived you are using. Please provide the output of keepalived -v.

There are a number of issues identified here:↳

1. There is no configuration keyword notify_ - see line notify_ /etc/keepalived/scripts/notify__mysql.sh #set read_only=0
2. Jun 17 20:42:49 oadb02 Keepalived_vrrp[144285]: (VI_1) Entering STATE is strange. It should say what state is being entered, i.e. BACKUP, FAULT or MASTER.
3. I can't see any log entry for entering MASTER state, despite the subject of this issue.
4. You have multiple (VI_1) received an invalid passwd! entries, but these are not consistent. What is happening that is causing the password that is being sent to change?

You haven't stated what version of keepalived you are using. Please provide the output of keepalived -v.↳

Thank you for your answer
The correct conf is as follows
global_defs
{
script_user root
enable_script_security
}
vrrp_script chk_mysql {
script "/etc/keepalived/scripts/check_mysql_health.sh"
weight -20
interval 1
timeout 30
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 90
advert_int 1
nopreempt
authentication {
auth_type PASS
auth_pass xxx654321
}
track_script {
chk_mysql
}
notify_master /etc/keepalived/scripts/notify_master_mysql.sh #set read_only=0
virtual_ipaddress {
172.16.32.51/24
}
}
the master priority is 100
the keepalived version is Keepalived v2.2.8 (04/04,2023), git commit v2.2.7-154-g292b299e+

3.There are no more records in the system logs
4.the received an invalid passwd maybe The password is longer than 8 characters

from keepalived.

There are still some unexplained issues.

1. Keepalived cannot log "Entering STATE", since the state being entered is always included in the log entry.
2. Despite the title of this issue, there are no log entries shown for entering MASTER state.
3. The length of the configured password being 9 is not an issue; keepalived simply truncates it. So what is causing the intermittent invalid passwords? Is there some other VRRP instance occasionally coming up on the network? Have you tried configuring the password to be only 8 characters long and seeing what happens then?

from keepalived.

There are still some unexplained issues.↳

1. Keepalived cannot log "Entering STATE", since the state being entered is always included in the log entry.
2. Despite the title of this issue, there are no log entries shown for entering MASTER state.
3. The length of the configured password being 9 is not an issue; keepalived simply truncates it. So what is causing the intermittent invalid passwords? Is there some other VRRP instance occasionally coming up on the network? Have you tried configuring the password to be only 8 characters long and seeing what happens then?

Ok, I'll try to change the password to 8 characters first, and then see how the problem happens
the tcpdump show
tcpdump -i eth0 vrrp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:04:37.939465 IP 172.16.32.a > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20
14:04:38.255026 IP 172.16.32.b > 224.0.0.18: VRRPv2, Advertisement, vrid 61, prio 100, authtype simple, intvl 1s, length 20
14:04:38.939519 IP 172.16.32.a > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20
14:04:39.255111 IP 172.16.32.b > 224.0.0.18: VRRPv2, Advertisement, vrid 61, prio 100, authtype simple, intvl 1s, length 20
14:04:39.939586 IP 172.16.32.a > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20
14:04:40.255197 IP 172.16.32.b > 224.0.0.18: VRRPv2, Advertisement, vrid 61, prio 100, authtype simple, intvl 1s, length 20
14:04:40.939668 IP 172.16.32.a > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20
14:04:41.255251 IP 172.16.32.b > 224.0.0.18: VRRPv2, Advertisement, vrid 61, prio 100, authtype simple, intvl 1s, length 20
14:04:41.939771 IP 172.16.32.a > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20
14:04:42.255349 IP 172.16.32.b > 224.0.0.18: VRRPv2, Advertisement, vrid 61, prio 100, authtype simple, intvl 1s, length 20
14:04:42.939824 IP 172.16.32.a > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20

from keepalived.

There are still some unexplained issues.↳

1. Keepalived cannot log "Entering STATE", since the state being entered is always included in the log entry.
2. Despite the title of this issue, there are no log entries shown for entering MASTER state.
3. The length of the configured password being 9 is not an issue; keepalived simply truncates it. So what is causing the intermittent invalid passwords? Is there some other VRRP instance occasionally coming up on the network? Have you tried configuring the password to be only 8 characters long and seeing what happens then?

Ok, I'll try to change the password to 8 characters first, and then see how the problem happens the tcpdump show tcpdump -i eth0 vrrp -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 14:04:37.939465 IP 172.16.32.a > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20 14:04:38.255026 IP 172.16.32.b > 224.0.0.18: VRRPv2, Advertisement, vrid 61, prio 100, authtype simple, intvl 1s, length 20 14:04:38.939519 IP 172.16.32.a > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20 14:04:39.255111 IP 172.16.32.b > 224.0.0.18: VRRPv2, Advertisement, vrid 61, prio 100, authtype simple, intvl 1s, length 20 14:04:39.939586 IP 172.16.32.a > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20 14:04:40.255197 IP 172.16.32.b > 224.0.0.18: VRRPv2, Advertisement, vrid 61, prio 100, authtype simple, intvl 1s, length 20 14:04:40.939668 IP 172.16.32.a > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20 14:04:41.255251 IP 172.16.32.b > 224.0.0.18: VRRPv2, Advertisement, vrid 61, prio 100, authtype simple, intvl 1s, length 20 14:04:41.939771 IP 172.16.32.a > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20 14:04:42.255349 IP 172.16.32.b > 224.0.0.18: VRRPv2, Advertisement, vrid 61, prio 100, authtype simple, intvl 1s, length 20 14:04:42.939824 IP 172.16.32.a > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20↳

hi
I stripped the keepalived logs out of the syslogs
I noticed something different
the switch log as follows, -------> Receive advertisement timeout

Jun 21 16:58:34 db02 Keepalived_vrrp[207609]: (VI_1) received an invalid passwd!
Jun 21 16:58:35 db02 Keepalived_vrrp[207609]: (VI_1) received an invalid passwd!
Jun 21 16:58:36 db02 Keepalived_vrrp[207609]: (VI_1) received an invalid passwd!
Jun 21 16:58:37 db02 Keepalived_vrrp[207609]: (VI_1) received an invalid passwd!
Jun 21 17:02:51 db02 Keepalived_vrrp[207609]: (VI_1) received an invalid passwd!
Jun 21 17:02:52 db02 Keepalived_vrrp[207609]: (VI_1) received an invalid passwd!
Jun 21 17:02:53 db02 Keepalived_vrrp[207609]: (VI_1) received an invalid passwd!
Jun 21 17:02:54 db02 Keepalived_vrrp[207609]: (VI_1) received an invalid passwd!
Jun 21 17:02:54 db02 Keepalived_vrrp[207609]: (VI_1) Receive advertisement timeout
Jun 21 17:02:54 db02 Keepalived_vrrp[207609]: (VI_1) Entering MASTER STATE
Jun 21 17:02:54 db02 Keepalived_vrrp[207609]: (VI_1) setting VIPs.
Jun 21 17:02:54 db02 Keepalived_vrrp[207609]: (VI_1) Sending/queueing gratuitous ARPs on eth0 for 172.16.32.x
Jun 21 17:02:54 db02 Keepalived_vrrp[207609]: Sending gratuitous ARP on eth0 for 172.16.32.x
Jun 21 17:02:54 db02 Keepalived_vrrp[207609]: Sending gratuitous ARP on eth0 for 172.16.32.x
Jun 21 17:02:54 db02 Keepalived_vrrp[207609]: Sending gratuitous ARP on eth0 for 172.16.32.x
Jun 21 17:02:54 db02 Keepalived_vrrp[207609]: Sending gratuitous ARP on eth0 for 172.16.32.x
Jun 21 17:02:54 db02 Keepalived_vrrp[207609]: Sending gratuitous ARP on eth0 for 172.16.32.x
Jun 21 17:02:54 db02 Keepalived_vrrp[207609]: (VI_1) Master received advert from 172.16.32.53 with higher priority 100, ours 90
Jun 21 17:02:54 db02 Keepalived_vrrp[207609]: (VI_1) Entering BACKUP STATE
Jun 21 17:02:54 db02 Keepalived_vrrp[207609]: (VI_1) removing VIPs.
Jun 21 17:21:15 db02 Keepalived_vrrp[207609]: (VI_1) received an invalid passwd!
Jun 21 17:21:16 db02 Keepalived_vrrp[207609]: (VI_1) received an invalid passwd!

from keepalived.