Client programs that have lost the connection to the HotStandby (HSB) primary server must be able to reconnect to the new primary server (the old secondary server). You must code client applications to be able to do the following tasks:
1 Recognize that the original primary server is not available for write transactions any more.
2 Connect to the new primary server or switch to using a previously created connection.
3 Take into account whether the current (interrupted) transaction was lost and must be re-executed on the new primary server.
Storing the secondary server address
When your application first connects to the primary server, the application can execute the following command (which gives the connection information for the other server in the HSB pair) and store the result:
ADMIN COMMAND 'hotstandby cominfo'
Note that when the 'hotstandby cominfo' command returns a value, it does not imply that the primary and secondary servers are currently connected.
Later, if the primary server fails, the application can use the stored information to attempt to connect to the secondary server (new primary server).
Detecting HotStandby server failure in client applications
To use HSB, applications must know when to switch from the failed primary server to the secondary (new primary) server. To do this, you can check the return codes from the functions that you call to see if you have received an error that indicates you should switch to the other server.
You can also monitor the states of the servers (for example, check the primary server to see whether the state has changed to PRIMARY UNCERTAIN).
The following errors indicate that you should try switching to another server:
10013: Transaction is read only 10041: Database is read only 10047: Replication transaction aborted 11002: Disk full 11003: File write failed, configuration exceeded 14501: Operation failed 14502: Invalid rpc parameter 14503: Communication error 14506: Server is closed (for example, because it is currently the target of an HSB netcopy operation) 14510: Communication write operation failed 14511: Communication read operation failed 14518: Connection broken 14519: User thrown out (for example, because of some administrative operation) 14529: Operation timed out 20009: Session error, write operation failed 21306: Server not found, connect failed 21308: Connection is broken (write failed with code ...) 21318: Operation failed (unusual return code)
ODBC applications
The following error message is returned to ODBC applications that cannot establish a connection (for example, due to an inoperable database server):
SQLState = 08001 - Client unable to establish connection
In addition, the following solidDB communication error message is produced:
21306 - Server 'server_name' not found, connection failed.
If a connection fails (for example, due to a network failure) in between operations, such as executing queries and fetching results, the following error message is returned:
SQLState = 08S01 - Communication link failure
JDBC applications
The following error message is returned to JDBC applications that cannot establish a connection (for example, due to an inoperable database):
SQLState = 08001 - Unable to connect to data source.
If a connection fails (for example, due to a network failure) in between operations, such as executing queries and fetching results, the following error message is returned:
SQLState = 08S01 - Communication link failure
Note ODBC and JDBC use different error messages for the same error code (08001).
Switching the application to the new primary server
After the application detects that it cannot send transactions to the original primary server, the application must poll the primary and secondary servers until it finds a server that is in PRIMARY ACTIVE, PRIMARY ALONE, or STANDALONE state.
Polling is accomplished by having the application attempt to connect to the servers and check the status of the servers when the connection is established. When the connection is successful, the client can request the server state by using SQL function HOTSTANDBY_STATE, see Using the HOTSTANDBY_STATE function.
Note After the switch, all open database objects, such as prepared statements, open cursors and transactions, are no longer active. Thus, you must initialize these objects again. Also, if you were using temporary tables or transient tables (see Non-persistent in-memory tables), the tables will be empty on the new primary server.