Replication use cases for global parallel clusters


Replication use cases for global parallel clusters
Prev	Configuring a global cluster with Volume Replicator and Storage Foundation Cluster File System High Availability or Storage Foundation for Oracle RAC	Next

For information on the VCS commands for global clusters:

See the Cluster Server Administrator's Guide.

If you have two clusters configured to use VVR for replication, the following replication use cases are supported:

Table: Replication use cases for global parallel clusters

Management option	Description
Migration of the role of the primary site to the remote site	Migration is a planned transfer of the role of primary replication host from one cluster to a remote cluster. This transfer enables the application on the remote cluster to actively use the replicated data. The former primary cluster becomes free for maintenance or other activity.
Takeover of the primary site role by the secondary site	Takeover occurs when an unplanned event (such as a disaster) causes a failure, making it necessary for the applications using the replicated data to be brought online on the remote cluster.
Migrate the role of primary site to the secondary site	See “To migrate the role of primary site to the remote site”.
Migrate the role of new primary site back to the original primary site	See “To migrate the role of new primary site back to the original primary site”.
Take over after an outage	See “To take over after an outage”.
Resynchronize after an outage	See “To resynchronize after an outage”.
Update the rlink	See “To update the rlink”.

After configuring the replication objects within VCS, you can use VCS commands to migrate the role of the cluster on the primary site to the remote cluster. In the procedure below, VCS takes the replicated database service group, database_grp, offline on the primary site and brings it online on the secondary site; the secondary site now assumes the role of the primary site.

Note:

The hagrp -switch command cannot migrate a parallel group within a cluster or between clusters in a global cluster environment.

To migrate the role of primary site to the remote site

From the primary site, use the following command to take the database service group offline on all nodes.
```
# hagrp -offline database_grp -any
```
Wait for VCS to take all database service groups offline on the primary site.
Verify that the RLINK between the primary and secondary is up to date. Use the vxrlink -g command with the status option and specify the RLINK for the primary cluster. You can use the command from any node on the primary cluster.
For example:
```
# vxrlink -g data_disk_group status rlk_clus2_dbdata_rvg
					
```
Where rlk_clus1_dbdata_rvg is the RLINK.
On the secondary site, which is now the new primary site, bring the database service group online on all nodes:
```
# hagrp -online database_grp -any
```

After migrating the role of the primary site to the secondary site, you can use VCS commands to migrate the role of the cluster on the new primary site to the original primary site. In the procedure below, VCS takes the replicated database service group, database_grp, offline on the new primary (former secondary) site and brings it online on the original primary site; the original primary site now resumes the role of the primary site.

Note:

The hagrp -switch command cannot migrate a parallel group within a cluster or between clusters in a global cluster environment.

To migrate the role of new primary site back to the original primary site

Make sure that all database resources are online, and switch back the group database_grp to the original primary site.
Issue the following command on the remote site:
```
# hagrp -offline database_grp -any
```
Verify that the RLINK between the primary and secondary is up to date. Use the vxrlink -g command with the status option and specify the RLINK for the primary cluster. You can use the command from any node on the current primary cluster.
For example:
```
# vxrlink -g data_disk_group status rlk_clus1_dbdata_rvg
					
```
Where rlk_clus1_dbdata_rvg is the RLINK.
Make sure that database_grp is offline on the new primary site. Then, execute the following command on the original primary site to bring the database_grp online:
```
# hagrp -online database_grp -any
```

Takeover occurs when the remote cluster on the secondary site starts the application that uses replicated data. This situation may occur if the secondary site perceives the primary site as dead, or when the primary site becomes inaccessible (perhaps for a known reason). For a detailed description of concepts of taking over the primary role:

See the Veritas InfoScale™ Replication Administrator's Guide.

Before enabling the secondary site to take over the primary role, the administrator on the secondary site must "declare" the type of failure at the remote (primary, in this case) site and designate the failure type using one of the options for the haclus command.

Takeover options are:

Table: Takeover options on global parallel clusters

Takeover option	Description
Disaster	When the cluster on the primary site is inaccessible and appears dead, the administrator declares the failure type as "disaster." For example, fire may destroy a data center, including the primary site and all data in the volumes. After making this declaration, the administrator can bring the service group online on the secondary site, which now has the role as "primary" site.
Outage	When the administrator of a secondary site knows the primary site is inaccessible for a known reason, such as a temporary power outage, the administrator may declare the failure as an "outage." Typically, an administrator expects the primary site to return to its original state. After the declaration for an outage occurs, the RVGSharedPri agent enables DCM logging while the secondary site maintains the primary replication role. After the original primary site becomes alive and returns to its original state, DCM logging makes it possible to use fast fail back resynchronization when data is resynchronized to the original cluster. Before attempting to resynchronize the data using the fast fail back option from the current primary site to the original primary site, take the precaution at the original primary site of making a snapshot of the original data. This action provides a valid copy of data at the original primary site for use in the case the current primary site fails before the resynchronization is complete.
Disconnect	When both clusters are functioning properly and the heartbeat link between the clusters fails, a split-brain condition exists. In this case, the administrator can declare the failure as "disconnect," which means no attempt will occur to take over the role of the primary site at the secondary site. This declaration is merely advisory, generating a message in the VCS log indicating the failure results from a network outage rather than a server outage.
Replica	In the rare case where the current primary site becomes inaccessible while data is resynchronized from that site to the original primary site using the fast fail back method, the administrator at the original primary site may resort to using a data snapshot (if it exists) taken before the start of the fast fail back operation. In this case, the failure type is designated as "replica".

The examples illustrate the steps required for an outage takeover and resynchronization.

To take over after an outage

From any node of the secondary site, issue the haclus command:
```
# haclus -declare outage -clus clus1
			
```
After declaring the state of the remote cluster, bring the database_grp service group online on the secondary site. For example:
```
# hagrp -online -force database_grp -any
			
```

To resynchronize after an outage

On the original primary site, create a snapshot of the Replicated Volume Group (RVG) before resynchronizing it in case the current primary site fails during the resynchronization. Assuming the disk group is data_disk_group and the RVG is dbdata1_rvg, type:
```
# vxrvg -g data_disk_group -F snapshot dbdata_rvg1
				
```
See the Veritas InfoScale™ Replication Administrator's Guide for details on RVG snapshots.
Resynchronize the RVG. From any node of the current primary site, issue the hares command and the -action option with the fbsync action token to resynchronize the RVGSharedPri resource. For example:
```
# hares -action dbdata_vvr_shpri fbsync -sys sys3
```
```
# vxdctl -c mode
			
```
Perform one of the following commands, depending on whether the resynchronization of data from the current primary site to the original primary site is successful:
- If the resynchronization of data is successful, use the vxrvg command with the snapback option to reattach the snapshot volumes on the original primary site to the original volumes in the specified RVG:
```
# vxrvg -g data_disk_group snapback dbdata_rvg1
```
- A failed attempt at the resynchronization of data (for example, a disaster hits the primary RVG when resynchronization is in progress) could generate inconsistent data.
  
  You can restore the contents of the RVG data volumes from the snapshot taken in step 1:
```
# vxrvg -g data_disk_group snaprestore dbdata_rvg1
```

If the rlink is not up to date, use the hares -action command with the resync action token to synchronize the RVG.

To update the rlink

The following command example is issued on any node (sys1, in this case) in the primary cluster, specifying the RVGSharedPri resource, dbdata_vvr_shpri:
```
# hares -action dbdata_vvr_shpri resync -sys sys1
```

Prev	Up	Next
Modifying the VCS configuration on the secondary site	Home	Section V. Implementing disaster recovery configurations in virtualized environments