solidDB Help : Configuring and administering : Configuring and administering HotStandby : HotStandby administration tasks : Choosing which server to make primary
  
Choosing which server to make primary
In some error recovery situations, you might not know which HotStandby (HSB) server you should make the primary server.
For example, in a case where both databases have failed; the server that was the primary server (before the servers lost contact with each other), is not necessarily the server that should become the primary server now.
To work out which server should be the primary server, complete the following steps:
1 Ensure that both servers are in SECONDARY ALONE state.
2 Connect to both servers.
3 In each server, run the following command:
ADMIN COMMAND 'hsb logpos';
This command returns the log operation ID and the server role (PRIMARY, SECONDARY, STANDALONE) at the time of the last operation. Successful ADMIN COMMAND commands return error code 0, a string, and the previous role of the server.
For example, the command might return the following output:
RC TEXT
-- ----
0 000000000000000000871:PRIMARY
The application must regard the string as an opaque value, which has no defined structure.
4 Compare the string values.
For example, in C, use the strcmp() function.
In principle, the server that has the greater value for the log operation ID has accepted more transactions, and thus should become the primary server. However, if you have made updates to both servers after the HSB connection has failed, the log operation ID values can no longer be compared reliably.
If HAC is used and the STRINGS are equal, the LocalDB.PreferredPrimary HAC parameter defines whether the local server becomes the primary server.
5 Select the primary server by running the following command on the server:
ADMIN COMMAND 'hsb set primary alone';
6 Connect the HSB servers with each other by running the following command:
ADMIN COMMAND 'hsb connect';
Results
If the hsb connect command succeeds, the secondary server catches up with the primary server, and the HSB pair is functional again.
If the hsb connect command fails, you must synchronize the nodes separately. For more information, see Synchronizing primary and secondary servers.
Important This procedure does not ensure that the server with the higher string value is a superset of the other server. The two servers might have each accepted transactions that the other did not. For example, both servers might have been running in the PRIMARY ALONE state. To detect the possibility that the primary server is not a superset of the secondary server, the servers compare information when the hsb connect command is run. If the primary server is not a superset, the hsb connect command fails with an appropriate error message.
Go up to
HotStandby administration tasks