High Availability Guide : Administering and configuring HotStandby : Administering HotStandby with ADMIN COMMANDs (HotStandby API) : Choosing which server to make primary
  
Choosing which server to make primary
In some error recovery situations, you might not know which server you must make the Primary. You can use the hsb logpos command to determine which server to make the Primary.
About this task
This procedure can be used, for example, in a case where both databases have failed; the server that was the Primary before the servers lost contact with each other is not necessarily the server that should become the Primary now.
Procedure
1 Ensure that both servers are in SECONDARY ALONE state.
2 Connect to both servers.
3 In each server, issue the following command:
ADMIN COMMAND 'hsb logpos';
This command returns the log operation ID and the server’s role (PRIMARY, SECONDARY, STANDALONE) at the time of the last operation. Successful admin commands return error code 0, a string, and the previous role of the server.
For example:
ADMIN COMMAND 'hsb logpos';
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. 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.
5 Select the Primary by using the following command on the server that will
become Primary:
ADMIN COMMAND 'hsb set primary alone';
6 Connect the HotStandby servers with each other by using the following command:
ADMIN COMMAND 'hsb connect';
Results
If the hsb connect command succeeds, the Secondary catches up with the Primary, and the HotStandby 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 neither server is a superset of the other, the servers compare information when the hsb connect command is issued. If neither server is a superset, the hsb connect command fails with an appropriate error message.
See also
Administering HotStandby with ADMIN COMMANDs (HotStandby API)