solidDB Help : Samples : HotStandby sample : Watchdog sample application : Failure situations and watchdog actions : Communication link between primary and secondary servers is down
  
Communication link between primary and secondary servers is down
Scenario
The connection between the primary and secondary servers is broken.
Symptoms
The primary server is not connected to the secondary server, the state of the primary server is PRIMARY UNCERTAIN, and the primary server no longer accepts transactions. The state of the secondary server is SECONDARY ALONE.
Note If the AutoPrimaryAlone parameter is set to Yes in solid.ini, the primary server switches to PRIMARY ALONE rather than PRIMARY UNCERTAIN and continues to accept transactions.
Remedy
The primary server can continue operations even when the link to the secondary server is down. If the primary server is not already in PRIMARY ALONE state, then switch the primary server to the PRIMARY ALONE state. After the link between the primary and secondary server is restored, synchronize the databases.
The following table describes the steps that should be taken by the watchdog and the administrator in order to return the service to normal operation.
 
Description
Illustration
Network connection between Server #1and Server #2 fails.
Server #1 switches to PRIMARY UNCERTAIN state automatically and suspends any open transactions.
Server #2 switches to SECONDARY ALONE state automatically.
The diagram is described in the first column of the row
The watchdog switches Server #1 to PRIMARY ALONE state. Server #1 starts accepting and processing transactions again, and saves transaction details in the log to send to Server #2.
Note If the transaction log on Server #1 fills up before the network connection is fixed, you might have to switch Server #1 to STANDALONE state.
The diagram is described in the first column of the row
The administrator fixes network connection between the servers.
The watchdog instructs Server #1 to connect to Server #2 by using the command:
ADMIN COMMAND 'hsb connect';
Server #2 reads the transaction log from Server #1.
Note If you switched Server #1 to STANDALONE state, you must copy the database from Server #1 to Server #2 before you reconnect the servers, see Synchronizing primary and secondary servers for details.
The diagram is described in the first column of the row
Further scenarios when the communication link between the primary and secondary server is down
If an application receives error message 10047 or 14537 from the primary server:
Try to connect to the secondary server to check if it is has become the new primary server.
If the old secondary server has not become the new primary server, see scenario in Primary server fails.
Go up to
Failure situations and watchdog actions