Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Cluster Geographic Edition Remote Replication Guide for Sun ZFS Storage Appliance Oracle Solaris Cluster 4.1 |
1. Configuring and Administering Sun ZFS Storage Appliance Protection Groups
2. Migrating Services That Use Sun ZFS Storage Appliance Remote Replication
Detecting Cluster Failure on a System That Uses Sun ZFS Storage Appliance Remote Replication
Migrating Services That Use Sun ZFS Storage Appliance Remote Replication With a Switchover
Actions Performed by the Geographic Edition Software During a Switchover
Forcing a Takeover on a System That Uses Sun ZFS Storage Appliance Remote Replication
How to Force Immediate Takeover of Sun ZFS Storage Appliance Services by a Secondary Cluster
Recovering Services to a Cluster on a System That Uses Sun ZFS Storage Appliance Replication
Overview of Recovering Services
How to Resynchronize and Revalidate the Protection Group Configuration
How to Perform a Failback-Switchover on a System That Uses Sun ZFS Storage Appliance Replication
How to Perform a Failback-Takeover on a System That Uses Sun ZFS Storage Appliance Replication
Recovering From a Sun ZFS Storage Appliance Remote Replication Error
How to Detect Remote Replication Errors
How to Recover From a Sun ZFS Storage Appliance Remote Replication Error
This section describes the internal processes that occur when failure is detected on a primary or a secondary cluster.
When the primary cluster for a protection group fails, the secondary cluster in the partnership detects the failure. The cluster that fails might be a member of more than one partnership, resulting in multiple failure detections.
The following actions take place when a primary cluster failure occurs. During a failure, the appropriate protection groups are in the Unknown state on the cluster that failed.
Heartbeat failure is detected by a partner cluster.
The heartbeat is activated in emergency mode to verify that the heartbeat loss is not transient and that the primary cluster has failed. The heartbeat remains in the Online state during this default time-out interval, while the heartbeat mechanism continues to retry the primary cluster.
This query interval is set by using the Query_interval heartbeat property. If the heartbeat still fails after the interval you configured, a heartbeat-lost event is generated and logged in the system log. When you use the default interval, the emergency-mode retry behavior might delay heartbeat-loss notification for about nine minutes. Messages are displayed in the graphical user interface (GUI) and in the output of the geoadm status command.
For more information about logging, see Viewing the Geographic Edition Log Messages in Oracle Solaris Cluster Geographic Edition System Administration Guide.
If the partnership is configured for heartbeat-loss notification, then one or both of the following actions occurs:
An email is sent to the address specified in the Notification_emailaddrs property.
The script defined in Notification_actioncmd is executed.
For more information about configuring heartbeat-loss notification, see Configuring Heartbeat-Loss Notification in Oracle Solaris Cluster Geographic Edition System Administration Guide.
When a secondary cluster for a protection group fails, a cluster in the same partnership detects the failure. The cluster that failed might be a member of more than one partnership, resulting in multiple failure detections.
During failure detection, the following actions take place:
Heartbeat failure is detected by a partner cluster.
The heartbeat is activated in emergency mode to verify that the secondary cluster is dead.
When a failure is confirmed by the Geographic Edition software, the cluster notifies the administrator. The system detects all protection groups for which the cluster that failed was acting as secondary. The state of the appropriate protection groups is marked Unknown.