|
STATE
|
DESCRIPTION
|
|---|---|
|
PRIMARY ACTIVE
|
The servers are connected, and this server (the Primary server) is accepting read/write transactions and sending the data to the Secondary server. The Secondary server must be in SECONDARY ACTIVE state.
|
|
PRIMARY ALONE
|
The peer servers are not interconnected. The peer might be up, but it is not connected and therefore is not accepting any transactions. The peer might be in the SECONDARY ALONE state).
This server (the Primary) is actively accepting and executing read/write transactions and collecting them to be sent to the Secondary later.
|
|
PRIMARY UNCERTAIN
|
The servers have disconnected abnormally and the AutoPrimaryAlone configuration parameter is set to No. In the PRIMARY UNCERTAIN state, any unacknowledged transactions remain in a pending status, which means that the server does not commit or roll back the transaction until HAC changes the server to another state.
The operator has three possible actions: reconnect the Primary to the Secondary, set the Primary server to PRIMARY ALONE state, or set the Primary server to SECONDARY ALONE state.
1 If the server is reconnected to the Secondary, then the transactions are committed on the Primary.
2 If the state is changed to PRIMARY ALONE, then the open transactions are committed on the Primary.
3 If the state is changed to SECONDARY ALONE, then the open transactions remain pending. They are finally resolved after the server changes to another state. For example, if the server is moved to the SECONDARY ACTIVE state, the blocked transactions are aborted or committed, depending on the catchup outcome. If the server state is changed to STANDALONE or PRIMARY ALONE, then the blocked transactions are committed.
If you want the Primary server to automatically go to PRIMARY ALONE rather than PRIMARY UNCERTAIN when it loses contact with the Secondary, then read the description of the AutoPrimaryAlone configuration parameter.
HAC can maximize safety by always switching the server from PRIMARY UNCERTAIN to SECONDARY ALONE. This prevents the possibility of dual primaries. However, it also prevents users from updating data on the server. For more information, see Network partitions and dual primaries.
|
|
SECONDARY ACTIVE
|
The peer servers are interconnected, and this server is accepting incoming transaction log data from the Primary. The transactions are executed on the Secondary so that it has the same data as the Primary. The transactions are also written to the transaction log of the Secondary so that the Secondary itself can recover the data if the Secondary fails. Additionally, clients can perform read-only transactions on a server in the SECONDARY ACTIVE state. When a server is in the SECONDARY ACTIVE state, the server's peer must be in PRIMARY ACTIVE state.
|
|
SECONDARY ALONE
|
The Secondary is disconnected from its peer server. Only read requests are accepted. The server can be connected to the peer by issuing the command HotStandby connect on either the Secondary or the Primary.
|
|
STANDALONE
|
The server has no HSB state (Primary or Secondary) and operates in the way a regular stand-alone server operates. Transaction logs are processed and removed in the normal way, too; they are not saved for the Secondary. To resume HSB operation, the server must be set to either PRIMARY ALONE or SECONDARY ALONE, and the Primary has to do a netcopy or copy operation to send a complete copy of the database to the Secondary.
|
|
OFFLINE
|
The server was started in “netcopy listen mode” (also called “backupserver mode”). In this mode, the server is waiting for an incoming netcopy from a server that is in PRIMARY ALONE state. When the server successfully completes netcopy, the server moves to the state SECONDARY ALONE.
You cannot directly observe the OFFLINE state because a server in OFFLINE state does not accept client connections. If you attempt to connect to a server in the OFFLINE state, error code 14552 Server is in backup server mode, no connections are allowed is returned. A server in the OFFLINE state responds only to a netcopy operation.
|