Network Failures
Perform a cutover from the originating instance to a replicating instance if the network from clients to the originating instance fails, and the network from the clients to the replicating instance is still functioning.
If the network from clients to both the originating and all available replicating instances fails, the application is no longer available.
If the network between the originating instance and replicating instance fails, no action is required to manage GT.M replication. The originating instance continues to make the application available. Replicating instances will catch up with the originating instance when the network is restored.
If the network from the clients to the replicating instance fails, no action is required to manage GT.M replication, although it would be prudent to make the network operational as soon as possible.
Single-Site Failure
Replicating Instance Fails
When the replicating instance comes back up after failure, it will still be the replicating instance. Refer to the preceding "Secondary Starts After a Shut Down or Crash" description for further details.
Originating instance Fails
If the originating instance fails, the replicating instance should take over; when the originating instance comes back up, it should come up as the new replicating instance.
The external control mechanism should detect that the originating instance has failed, and take action to switch the replicating instance to originating mode, and either route transactions to the new originating instance (former replicating instance) or notify clients to route transactions to the new originating instance.
If the former originating instance did not respond to certain transactions, one cannot be certain whether they were processed and whether or not the database updates were committed to the former replicating instance. These transactions must now be processed on the new replicating instance. When the former originating instance comes up as the new replicating instance, GT.M rolls off the processed transactions and database updates for reconciliation on the new originating instance.
On new originating instance (former replicating instance)
Stop the Replication Server.
Create new journal files.
Switch the Source Server from passive to active mode to start replicating to the new replicating instance (former originating instance) when it comes back up.
Start the application servers, or if they were passive, they should be activated. The new originating instance is now ready to receive transactions from clients.
If the state of the database indicates that batch operations were in process, restart batch operations.
When the new replicating instance (the former originating instance) comes back up, query the originating instance for the journal sequence number at which it became the originating instance (refer to “Displaying/Changing the attributes of Replication Instance File and Journal Pool” for more information), and roll back the replicating instance to this point (refer to Section : “Rolling Back the Database After System Failures ” for more information). Reconcile the transaction from the lost transaction file or possibly the broken transaction file resulting from the rollback operation.
Create new journal files.
Start the Source Server in passive mode.
Start the Receiver Server to resume replication as the new replicating instance. Dual-site operation is now restored.
As appropriate, start the passive application servers.