In the basic HotStandby (HSB) server scheme, there are two database servers, the primary server and the secondary server. Each server has a disk drive on which the database is stored, and a transaction log (Txn log).
HSB uses the primary server transaction log, which contains a copy of the transactions that are committed on the server and is used by all solidDB servers to recover data if the server shuts down abnormally.
The primary server writes a transaction to its transaction log and sends the same data to the secondary server so that the secondary server can make identical changes to its copy of the database. The secondary server runs a continuous roll-forward process that receives the data and keeps the copy of the data on the secondary server synchronized with the data on the primary server.
The transaction log on the secondary server is not actively involved in HSB, but it is maintained so that the secondary server can recover data that was committed but not yet written to the database.
Failover
If the primary server fails, a watchdog application tells the secondary server to become the primary server. When the new primary server is in operation, the clients can connect to the new primary server and continue working.
Clients continue to see all data that was committed before the primary server failed. However, clients must restart any transactions that were started but not committed when the original primary server failed.
The new primary server can operate alone and continue to write transactions and data to its database and transaction log.
When the original primary server has recovered, it becomes the secondary server and receives log data from the new primary server in order to synchronize its copy of the database.
If the secondary server fails, the primary server continues to operate. The primary server continues writing data to the transaction log and keeps the transaction log entries until the secondary server has recovered, reconnected with the primary server, and received the transaction log entries from the primary server.
The length of time for which the primary server keeps the log depends upon the General.CheckpointDeleteLog and General.BackupDeleteLog settings in solid.ini, see General section.
Note If the primary server is unable to contact the secondary server for a long time, the transaction log can fill all the available disk space. You can avoid running out of disk space by applying appropriate configuration parameter settings. For more information, see Running out of space for transaction logs.
Heartbeat
Internally, HSB uses a technique that is referred to as a heartbeat, to monitor the connection between servers.
Each server continuously sends unidirectional ‘keepalive’ messages to the other server. The messages are sent on a fixed time interval. A message from the other server is expected to arrive within a predefined time window.
Note In solidDB the heartbeat technique is called a ping, although there are no ping requests sent. The heartbeat technique is different from the ‘ping’ protocol used in Internet Protocol networks.
Server states
In an HSB system, each server is in one of several possible states that describes the current behavior of the server.
For example, when the primary and secondary servers are communicating and synchronizing, they are in the PRIMARY ACTIVE and SECONDARY ACTIVE states.
Alternatively, if the primary server loses contact with the secondary server, the primary server switches to the PRIMARY UNCERTAIN state automatically. In that state, it does not accept new transactions. The administrator or, more typically the High Availability Controller (HAC), can switch the server to the PRIMARY ALONE state. In the PRIMARY ALONE state, the server acts as an independent server, accepts new transactions, and stores the transaction to send to the secondary server when the secondary server is available.
