|
Description
|
Illustration
|
|---|---|
|
The primary server (Server #1) writes data (in record level format) to the transaction log.
|
 |
|
When the primary server encounters a commit statement, all changed data is sent to the secondary server (Server #2).
Note If the secondary server fails after the transaction starts and before the primary server sends the data, then the primary server rolls back the transaction.
|
 |
|
The secondary server acknowledges the commit message. The timing of the acknowledgment depends upon the setting of the HotStandby.2SafeAckPolicy configuration parameter, see HotStandby section.
When the primary server receives the acknowledgment, the primary server notifies the user that the data has been committed.
|
 |
|
If the primary server does not receive acknowledgment from the secondary server (for example, because of a server failure), the primary server switches to PRIMARY UNCERTAIN state. The primary server is unable to roll back or commit the transaction because the primary server does not know which of the following situations occurred:
▪ The secondary server was down before the transaction was committed.
▪ The secondary server already committed the transaction, but the primary server did not receive the acknowledgment.
While the server is in PRIMARY UNCERTAIN state, the current transaction and new transactions that a user tries to commit are blocked and the user might perceive that the server is unresponsive.
|
 |
|
If a watchdog application (for example, the High Availability Controller (HAC), see High Availability Controller), detects that the secondary server is down or the network has failed, it can switch the primary server to PRIMARY ALONE state.
When the primary server is set to PRIMARY ALONE, it commits the pending transactions that were sent to the secondary server and resumes accepting and committing new transactions.
|
 |
|
Changes accumulate in the transaction log file until the secondary server is back in operation or until the primary server runs out of disk space.
If the server runs out of disk space for the transaction log, the primary server changes to read-only mode.
|
 |
|
If the primary server is likely to run out of disk space for the transaction log, you can switch the primary server from PRIMARY ALONE to STANDALONE state.
In STANDALONE state, the transaction log does not store all the transactions that occur since contact was lost with the secondary server. However, when both primary and secondary servers are active again, the secondary server cannot catch up only by reading the transaction logs from the primary server.
|
 |
|
When the secondary server is recovered, it starts in SECONDARY ALONE state.
If the secondary server cannot be brought up to date with the transaction logs, you must copy the primary database files to the secondary server. This can be done by using the command:
ADMIN COMMAND 'hsb netcopy'
To execute this command, the primary server must be in the PRIMARY ALONE state.
After the 'hsb netcopy' command is executed, the primary server remains in the PRIMARY ALONE state, regardless of whether the command succeeds or fails.
|
 |
|
In order for the primary server to start sending transactions to the secondary server again, the primary server must be connected to the secondary server by using the command:
ADMIN COMMAND 'hsb connect'.
|
 |
|
After the primary server is connected to the secondary server, the primary server changes to the PRIMARY ACTIVE state and the secondary server to SECONDARY ACTIVE state.
After the servers are connected, all pending changes are automatically written from the transaction log on the primary server to the secondary server to resynchonize the database. Before this activity starts, the primary and secondary servers exchange information and determine where to begin the task in order to ensure that a transaction is not committed twice on the secondary server.
|
 |