Creating a Role-Change Action Script

You can configure the Geographic Edition software to run a command when a cluster within a protection group changes from the secondary to the primary role. This change can happen as a result of either a switchover or takeover operation.

The action command runs during a switchover or takeover on the new primary cluster when the protection group is started on the new primary cluster. The script is invoked on the new primary cluster after the data replication role changes from secondary to primary and before the application resource groups are brought online. If the data replication role change does not succeed, then the script is not called.

The path to this script should be valid on all nodes of all partner clusters that can host the protection group.

The following command-line runs the script:

# custom-action-command-path -o primary -c clustername \
-s partnershipname protectiongroupname userarguments

customactioncommandpath

Specifies a path to the action command you have created.

-o primary

Specifies that the role being assumed by the cluster is primary.

-c clustername

Specifies the name of the secondary cluster that is assuming the new role of primary cluster.

-s partnershipname

Specifies the name of the partnership that hosts the protection group.

protectiongroupname

Specifies the name of the protection group that is undergoing the role change.

userarguments

Specifies static arguments that are passed after all the Geographic Edition supplied options.

This free-form string can be parsed by the script as required. For example, you could specify a list of key=value pairs, such as name=oracle.com,ip=10.1.2.3. You could also specify a sequence of options, such as -n oracle.com -a 10.1.2.3.4. The format of these arguments is not restricted by the Geographic Edition software.

The exit status of the role-change action script is reported as part of the result of the geopg switchover or geopg takeover command. The exit status is zero if the action script was started successfully. A nonzero exit status indicates an error or failure. The value of the exit status does not affect other aspects of the role-change actions. The switchover or takeover proceeds to bring the application resource groups in the protection group online, regardless of the exit status of the action script.

The Geographic Edition software waits for the script to return before the software processes operations such as bringing online application resource groups. Therefore, you must know in advance the amount of time required to run the script when you create the action script so that you can set the timeout period for the protection group accordingly. Setting the timeout period to include enough time for the script to complete to avoid switchovers or takeovers timing out and leaving the application resource group offline on the new primary.

Example 9-1 Switchover Action Script for Updating the DNS

This sample script uses the nsupdate command to reconfigure the host name to point to a new cluster. For more information about the nsupdate command, refer to the nsupdate(1M) man page.

Clients that try to connect to companyX.com are referred by the name service to the address of the primary cluster for a protection group, cluster-paris. When the primary cluster fails to respond, the administrator performs a switchover of the protection group to the alternative cluster, cluster-newyork.

#!/bin/ksh
# sample script to update dns
# Assumes each cluster has an entry with name "lh-paris-1" in /etc/hosts
# but different value for the IP in each cluster
# for forward DNS (A) entry: will delete old entry for "lh-paris-1"
# and add one that is correct for "this cluster"
#
# For reverse (PTR) DNS entry, will just add one for this cluster. 
# Will NOT delete PTR record left over from old cluster. So
# eventually you will just have reverse lookup for the IP for both clusters
# doing reverse resolution to the same name (lh-paris-1.odyssey.com)
# This should be fine, as long as the forward resolution stays "correct"
#
# The blank line of input at the end of nsupdate is REQUIRED
#
# A short TTL is put on the new records (600 = 10 minutes)
# but you can't really control what kind of caching goes on on
# the client side


# get IP corresponding to name "lh-paris-1" on THIS Cluster
NEWIP=$(getent hosts lh-paris-1|cut -f1)

# this bit splits out the octets in order to add the reverse PTR entry
IFS=.
set $NEWIP
unset IFS

/usr/sbin/nsupdate <<ENDNSUPDATE
update delete ora-lh.odyssey.com A
update add ora-lh.odyssey.com 600 A $NEWIP
update add $4.$3.$2.$1.in-addr.arpa 600 PTR ora-lh.odyssey.com.

ENDNSUPDATE