Universal Cache User Guide : Failure handling in Universal Cache : solidDB® server in HA mode (HotStandby) fails
  
solidDB® server in HA mode (HotStandby) fails
The following sections describe failure scenarios in a HotStandby configuration.
Primary solidDB® server fails
If the primary solidDB® server fails, a high availability manager, like the High-Availability Controller (HAC), performs a failover to the secondary solidDB® server as a standard procedure. If the 2-Safe protocol is used, the database and log states are fully preserved. The applications perceive a failover time of less than one second.
If the solidDB® database is a source datastore (write-only cache where the data is replicated only from the frontend to the backend), the IBM InfoSphere CDC instance reconnects automatically to the new primary, and replication continues.
If the solidDB® database is a target datastore (read-only or read-write cache), replication on the subscriptions ends. The subscription needs to be restarted with the Management Console or with the IBM InfoSphere CDC command dmstartmirror.
For instructions, see “Starting and ending replication on subscriptions” in the IBM InfoSphere Change Data Capture Management Console, Administration Guide.
During the scenario above, the IBM InfoSphere CDC instance is in operation all the time.
For more information about the HA (HotStandby) functionality and the High-Availability Controller (HAC), see the solidDB® High Availability User Guide.
Secondary solidDB® frontend fails
In the case of secondary frontend failure, no manual intervention is needed.
If the secondary frontend fails, the secondary frontend node is recovered in a normal way that is specific to the installation (for example, automatically rebooted). HAC automatically performs the rest of the recovery. The failure is not visible to applications or to the IBM InfoSphere CDC instance.
See also
Failure handling in Universal Cache