To restart an application, the application needs to know its state
at the time of the failover or switchover.
State information is application specific; therefore, the application must
determine what information is needed. Without any state information, the application
can be restarted on your PC. However, you will must reestablish your position
within the application.
Several methods are available to save application state information for
the backup system. Each application needs to determine which method works
best for it.
- The application can transfer all state information to the requesting client
system. When a switchover or failover occurs, the application uses the stored
state on the client to reestablish the state in the new server. This can
be accomplished by using the Distribute Information API or Clustered Hash
Table APIs.
- The application can replicate state information (such as job information
and other control structures that are associated with the application) on
a real-time basis. For every change in the structures, the application ships
the change over to the backup system.
- The application can store pertinent state information that is associated
with its application in the exit program data portion of the cluster resource
group for that application. This method assumes that a small amount of state
information is required. You can use the Change Cluster Resource
Group (QcstChangeClusterResourceGroup) API to do this.
- The application can store state information in a data object that is being
replicated to the backup systems along with the application's data.
- The application can store state information in a data object contained
in the switchable IASP that also contains the application's data.
- The application can store the state information about the client.
- No state information is saved, and you need to perform the recovery.
Note: The amount of information that is required to be saved is lessened if
the application uses some form of checkpoint-restart processing. State information
is only saved at predetermined application checkpoints. Restart then takes
you back to the last known checkpoint which is similar to how database's commitment
control processing works.