How Keepalived Powers High-Availability for MySQL and RabbitMQ

Overview

This summary describes how Keepalived implements a high‑availability (HA) solution for Linux‑based services such as MySQL and RabbitMQ. It explains the role of the Virtual Router Redundancy Protocol (VRRP), the floating Virtual IP (VIP), health‑check scripts, and the failover sequence, and provides a minimal configuration example.

Keepalived and VRRP

Keepalived runs on Linux and uses VRRP to elect a master node among a group of servers. The master periodically broadcasts VRRP advertisement packets (heartbeat). Backup nodes listen for these packets; if a backup does not receive an advertisement within the configured advert_int plus a small grace period, it assumes the master has failed and initiates a takeover.

Virtual IP (VIP)

The VIP is a floating address that is not bound to any physical interface. Clients always connect to the VIP; when a failover occurs, Keepalived moves the VIP from the failed node to the selected backup, making the transition transparent to the client.

Middleware health‑check scripts

Keepalived can invoke external scripts to verify that the protected services are healthy. A script must exit with status 0 when the service is operational and non‑zero otherwise. The result influences the track_script directive, causing VRRP to downgrade the node’s priority or trigger a failover.

# Example health‑check for MySQL ( /etc/keepalived/check_mysql.sh )
#!/bin/bash
mysqladmin ping -h127.0.0.1 -uroot &>/dev/null
if [ $? -eq 0 ]; then
  exit 0   # healthy
else
  exit 1   # unhealthy
fi

# Example health‑check for RabbitMQ ( /etc/keepalived/check_rabbitmq.sh )
#!/bin/bash
curl -s http://127.0.0.1:15672/api/overview | grep -q '"status":"ok"'
if [ $? -eq 0 ]; then
  exit 0
else
  exit 1
fi

Failover workflow

Master node sends VRRP advertisements at the interval defined by advert_int.

Backup nodes receive the advertisements and keep the VIP on the master.

If a health‑check script on the master returns a non‑zero exit code, Keepalived reduces the master’s priority.

If the master stops sending advertisements (node crash or priority drop), the highest‑priority backup assumes the VIP.

The new master starts the required service (MySQL or RabbitMQ) if it is not already running.

Minimal Keepalived configuration

vrrp_instance VI_1 {
    state MASTER               # or BACKUP on secondary nodes
    interface eth0              # network interface for the VIP
    virtual_router_id 51       # must be the same on all nodes
    priority 150               # higher value = preferred master
    advert_int 1               # heartbeat interval in seconds
    authentication {
        auth_type PASS
        auth_pass 1234abcd
    }
    virtual_ipaddress {
        192.168.10.100/24      # VIP
    }
    track_script {
        chk_mysql
        chk_rabbitmq
    }
}

# Define health‑check scripts for tracking
vrrp_script chk_mysql {
    script "/etc/keepalived/check_mysql.sh"
    interval 5               # run every 5 seconds
    weight -20                # lower priority if script fails
}

vrrp_script chk_rabbitmq {
    script "/etc/keepalived/check_rabbitmq.sh"
    interval 5
    weight -20
}

Testing and verification

Start Keepalived on both nodes and verify that ip addr show lists the VIP only on the master.

Stop the MySQL service on the master; observe that the health‑check script fails, the master’s priority drops, and the backup takes over the VIP.

Repeat the test for RabbitMQ to confirm both services are covered.

By correctly configuring VRRP, the VIP, and health‑check scripts, Keepalived provides automatic, seamless failover for MySQL and RabbitMQ, ensuring continuous service availability.