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.
Observe the following requirements for the role-change action script:
The path to this script must be valid on all nodes of all partner clusters that can host the protection group.
The script must have execute permissions for the user that launches the script. The intended user can be the root role, or an administrator with the necessary solaris.cluster.* authorization to execute a switchover or takeover operation plus any other actions that the script performs. For more information about user rights for Geographic Edition software, see Chapter 4, Administering RBAC.
The script must begin with the path to the shell, such as #!bin/ksh.
The following command-line runs the script:
# custom-action-command-path -o primary -c cluster-name \ -s partnership-name protection-group user-arguments
Specifies a path to the action command you have created.
Specifies that the role being assumed by the cluster is primary.
Specifies the name of the secondary cluster that is assuming the new role of primary cluster.
Specifies the name of the partnership that hosts the protection group.
Specifies the name of the protection group that is undergoing the role change.
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 exit status of the action script can impact the geomg switchover or geomg takeover commands. During switchover or takeover of a multigroup, if the action script returns a nonzero exit status for a protection group that has dependents, the switchover or takeover of those dependent protection groups is not performed.
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 12-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