Skip Navigation Links
Exit Print View
| Oracle Solaris Cluster Geographic Edition System Administration Guide

Search Scope:

- This Document
- Entire Library

## 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=sun.com,ip=10.1.2.3`. You could also specify a sequence of options, such as `-n sun.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

Copyright © 2004, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |