The software described in this documentation is either in Extended Support or Sustaining Support. See https://www.oracle.com/us/support/library/enterprise-linux-support-policies-069172.pdf for more information.
Oracle recommends that you upgrade the software described by this documentation as soon as possible.

17.11 About Keepalived Notification and Tracking Scripts

Notification scripts are executable programs that Keepalived invokes when a server changes state. You can implements notification scripts to perform actions such as reconfiguring a network interface or starting, reloading or stopping a service.

To invoke a notification script, include one the following lines inside a vrrp_instance or vrrp_sync_group section:

notify program_path

Invokes program_path with the following arguments:

$1

Set to INSTANCE or GROUP, depending on whether Keepalived invoked the program from vrrp_instance or vrrp_sync_group.

$2

Set to the name of the vrrp_instance or vrrp_sync_group.

$3

Set to the end state of the transition: BACKUP, FAULT, or MASTER.

notify_backup program_path , notify_backup "program_path arg ..."

Invokes program_path when the end state of a transition is BACKUP. program_path is the full pathname of an executable script or binary. If a program has arguments, enclose both the program path and the arguments in quotes.

notify_fault program_path , notify_fault "program_path arg ..."

Invokes program_path when the end state of a transition is FAULT.

notify_master program_path , notify_master "program_path arg ..."

Invokes program_path when the end state of a transition is MASTER.

The following executable script could be used to handle the general-purpose version of notify:

#!/bin/bash

ENDSTATE=$3
NAME=$2
TYPE=$1

case $ENDSTATE in
    "BACKUP") # Perform action for transition to BACKUP state
              exit 0
              ;;
    "FAULT")  # Perform action for transition to FAULT state
              exit 0
              ;;
    "MASTER") # Perform action for transition to MASTER state
              exit 0
              ;;
    *)        echo "Unknown state ${ENDSTATE} for VRRP ${TYPE} ${NAME}"
              exit 1
              ;;
esac

Tracking scripts are programs that Keepalived runs at regular intervals, according to a vrrp_script definition:

vrrp_script script_name {
  script       "program_path arg ..."
  interval i  # Run script every i seconds
  fall f      # If script returns non-zero f times in succession, enter FAULT state
  rise r      # If script returns zero r times in succession, exit FAULT state
  timeout t   # Wait up to t seconds for script before assuming non-zero exit code
  weight w    # Reduce priority by w on fall
}

program_path is the full pathname of an executable script or binary.

You can use tracking scripts with a vrrp_instance section by specifying a track_script clause, for example:

vrrp_instance instance_name {
  state MASTER
  interface eth0
  virtual_router_id 21
  priority 200
  advert_int 1
  virtual_ipaddress {
    10.0.0.10/24
  }
  track_script {
    script_name
    ...
  }
}

If a configured script returns a non-zero exit code f times in succession, Keepalived changes the state of the VRRP instance or group to FAULT, removes the virtual IP address 10.0.0.10 from eth0, reduces the priority value by w and stops sending multicast VRRP packets. If the script subsequently returns a zero exit code r times in succession, the VRRP instance or group exits the FAULT state and transitions to the MASTER or BACKUP state depending on its new priority.

If you want a server to enter the FAULT state if one or more interfaces goes down, you can also use a track_interface clause, for example:

  track_interface {
    eth0
    eth1
  }

A possible application of tracking scripts is to deal with a potential split-brain condition in the case that some of the Keepalived servers lose communication. For example, a script could track the existence of other Keepalived servers or use shared storage or a backup communication channel to implement a voting mechanism. However, configuring Keepalived to avoid a split brain condition is complex and it is difficult to avoid corner cases where a scripted solution might not work.

For an alternative solution, see Section 17.12, “Making HAProxy Highly Available Using Oracle Clusterware”.