JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Cluster Geographic Edition Data Replication Guide for EMC Symmetrix Remote Data Facility     Oracle Solaris Cluster 4.1
search filter icon
search icon

Document Information

Preface

1.  Replicating Data With EMC Symmetrix Remote Data Facility Software

2.  Administering SRDF Protection Groups

3.  Migrating Services That Use SRDF Data Replication

Detecting Cluster Failure on a System That Uses SRDF Data Replication

Detecting Primary Cluster Failure

Detecting Secondary Cluster Failure

Migrating Services That Use SRDF Data Replication With a Switchover

Validations That Occur Before a Switchover

Results of a Switchover From a Replication Perspective

How to Switch Over an SRDF Protection Group From Primary to Secondary

Forcing a Takeover on a System That Uses SRDF Data Replication

Validations That Occur Before a Takeover

Results of a Takeover From a Replication Perspective

How to Force Immediate Takeover of SRDF Services by a Secondary Cluster

Recovering Services to a Cluster on a System That Uses SRDF Replication

How to Resynchronize and Revalidate the Protection Group Configuration

How to Perform a Failback-Switchover on a System That Uses SRDF Replication

How to Perform a Failback-Takeover on a System That Uses SRDF Replication

Recovering From a Switchover Failure on a System That Uses SRDF Replication

Switchover Failure Conditions

Recovering From Switchover Failure

How to Make the Original Primary Cluster Primary for an SRDF Protection Group

How to Make the Original Secondary Cluster Primary for an SRDF Protection Group

Recovering From an SRDF Data Replication Error

How to Detect Data Replication Errors

How to Recover From an SRDF Data Replication Error

A.  Geographic Edition Properties for SRDF

Index

Forcing a Takeover on a System That Uses SRDF Data Replication

Perform a takeover when applications need to be brought online on the secondary cluster regardless of whether the data is completely consistent between the primary volume and the secondary volume. The information in this section assumes that the protection group has been started.

The following steps occur after a takeover is initiated:

For more details about takeover and the effects of the geopg takeover command, see Appendix C, Disaster Recovery Administration Example, in Oracle Solaris Cluster Geographic Edition System Administration Guide.

For details about the possible conditions of the primary and secondary cluster before and after takeover, see Appendix D, Takeover Postconditions, in Oracle Solaris Cluster Geographic Edition System Administration Guide.

The following sections describe the steps you must perform to force a takeover by a secondary cluster.

Validations That Occur Before a Takeover

When a takeover is initiated by using the geopg takeover command, the data replication subsystem runs several validations on both clusters. These step are conducted on the original primary cluster only if the primary cluster can be reached. If validation on the original primary cluster fails, the takeover still occurs.

First, the replication subsystem checks that the SRDF device group is in a valid aggregate RDF pair state. The SRDF commands that are used for the takeover are described in the following table.

Table 3-2 SRDF Takeover Validations on the New Primary Cluster

Aggregate RDF Pair State
Protection Group Local Role
SRDF Takeover Commands That Are Run on cluster-newyork
FailedOver
Primary
symrdf $option $dg write_disable r2

symrdf -g dg suspend

symrdf $option $dg rw_enable r1

FailedOver
Secondary
No command is run.
Synchronized, Suspended, R1 Updated, Partitioned
All
symrdf -g dg failover

Results of a Takeover From a Replication Perspective

From a replication perspective, after a successful takeover, the Local-role property of the protection group is changed to reflect the new role, regardless of whether the application could be brought online on the new primary cluster as part of the takeover operation. On cluster-newyork, where the protection group had a Local-role of Secondary, the Local-role property of the protection group becomes Primary. On cluster-paris, where the protection group had a Local-role of Primary, the following might occur:

If the takeover is successful, the applications are brought online. You do not need to run a separate geopg start command.


Caution

Caution - After a successful takeover, data replication between the new primary cluster, cluster-newyork, and the old primary cluster, cluster-paris, is stopped. If you want to run a geopg start command, you must use the -n option to prevent replication from resuming.


How to Force Immediate Takeover of SRDF Services by a Secondary Cluster

Before You Begin

Before you force the secondary cluster to assume the activity of the primary cluster, ensure that the following conditions are met:

  1. Log in to a node in the secondary cluster.

    You must be assigned the Geo Management RBAC rights profile to complete this procedure. For more information about RBAC, see Geographic Edition Software and RBAC in Oracle Solaris Cluster Geographic Edition System Administration Guide.

  2. Initiate the takeover.
    # geopg takeover [-f] protectiongroupname
    -f

    Forces the command to perform the operation without your confirmation

    protectiongroupname

    Specifies the name of the protection group

Example 3-2 Forcing a Takeover by a Secondary Cluster

This example forces the takeover of srdfpg by the secondary cluster cluster-newyork.

The phys-newyork-1 cluster is the first node of the secondary cluster. For a reminder of which node is phys-newyork-1, see Example Geographic Edition Cluster Configuration in Oracle Solaris Cluster Geographic Edition System Administration Guide.

phys-newyork-1# geopg takeover -f srdfpg

Next Steps

For information about the state of the primary and secondary clusters after a takeover, see Appendix D, Takeover Postconditions, in Oracle Solaris Cluster Geographic Edition System Administration Guide.