The purpose of a HotStandby replication protocol is to carry the transaction results safely from the primary server to the secondary server. solidDB® offers both synchronous (2-safe) and asynchronous (1-safe) replication protocols. Together with various durability (logging) levels, the replication protocol t can be used to tune the HotStandby system to the required balance between performance and endurance.
▪1-safe: the transaction is first committed at Primary and then transmitted to Secondary
▪2-safe: the transaction is not committed before it has been acknowledged by Secondary (default).
The safeness level can be controlled at three levels:
▪Global – HotStandby.SafenessLevel parameter
▪Session – SET SAFENESS statement
▪Transaction – SET TRANSACTION SAFENESS statement
Synchronous HotStandby with 2-safe replication
To ensure that the Primary and Secondary have the same data, solidDB® uses, primarily, a synchronous HotStandby model. It is called a 2–safe replication method; the data is written in two places before the user is told that the data has been committed.
Before committing changes to a transaction in the Primary database, the Primary server sends the transaction data to the Secondary server. The Secondary server must send acknowledgement to the Primary that it has committed or at least received the data. Otherwise, the Primary server times out and changes its state from PRIMARY ACTIVE to PRIMARY UNCERTAIN. In this case, the Primary server cannot roll back or commit the transaction. The HAC can set the Primary server to PRIMARY ALONE state, which allows the Primary to continue to receive transactions and operate independently of the Secondary. It commits the pending transactions that were sent to the Secondary and resumes accepting new transactions.
Note The Secondary server sends an acknowledgement as soon as it has committed (or at least received) the transaction log entries. This configuration prevents lost transactions when there is a single failure. Additionally, a file-based transaction log is optionally retained to facilitate database recovery in case a total system failure occurs.
Basic steps in sending data
Sending data with synchronous replication includes the following steps:
1 The Primary server writes data (in record level format) to the transaction log at the Primary node.
2 When the Primary server encounters a commit statement, all changed data is sent to the Secondary server.
Note If the Secondary server fails after the transaction starts and before the Primary sends the data, then the Primary will roll back the transaction.
3 The Secondary acknowledges the commit message. The timing of the acknowledgement depends upon the setting of the HotStandby.2SafeAckPolicy configuration parameter. With the fastest alternative, 2-safe received, the Secondary sends acknowledgement to the Primary immediately upon receiving the commit message. With the safest alternative, 2-safe durable, the Secondary sends acknowledgement after it has executed and written the transaction durably to its own transaction log.
When the Primary receives the acknowledgement, the Primary notifies the user that the data has been committed.
4 If the Primary does not receive acknowledgement from the Secondary (for example, because of a network failure or node failure), the Primary server times out and switches to the PRIMARY UNCERTAIN state. The Primary is unable to roll back or commit the transaction itself because it does not know the state of recent transactions in the Secondary. The Primary does not know which of the following happened:
▪The Secondary was down before the transaction was committed.
▪The Secondary already committed the transaction, but the Primary server did not receive acknowledgement, for example because of network failure.
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.
5 If the HAC detects that the Secondary is down or the network has failed, it can switch the Primary server to the PRIMARY ALONE state. When the Primary server is set to PRIMARY ALONE, it commits the pending transactions that were sent to the Secondary and resumes accepting new transactions.
6 Changes are accumulated to the transaction log file until the Secondary server is back in operation or until the Primary server is out of disk space. If the server runs out of disk space for the transaction log, the Primary changes to read-only mode.
7 If the Secondary server is out of operation for a long time and the server is likely to run out of disk space for the transaction log, you might want to switch the Primary server from PRIMARY ALONE to STANDALONE state. This means that the transaction log does not store all transactions since contact was lost with the Secondary, and therefore the Secondary cannot catch up only by reading the transaction logs from the Primary. If the Secondary cannot be brought up to date with the transaction logs, the only way to synchronize the Secondary with the Primary is to copy its database files to the Secondary. This can be done with the hotstandby netcopy command.
8 To execute hotstandby netcopy, the Primary must be in the PRIMARY ALONE state. After hotstandby netcopy, the Primary server remains in the PRIMARY ALONE state, regardless of whether the command succeeds or fails.
9 In order for the Primary to start sending its transactions to the Secondary again, the Primary server must be connected explicitly to the Secondary server by using the command hotstandby connect. After the Primary server is connected to the Secondary server, the Primary operates in the PRIMARY ACTIVE state.
After the servers are connected, they start performing catchup – when all pending changes are automatically written from the transaction log to the Secondary to keep in sync with the Primary. Before server catchup, the Primary and Secondary exchange information and determine where to begin the catchup so that a transaction is not committed twice on the Secondary.
Optionally, asynchronous replication from Primary to Secondary can be used. This is called 1-safe replication.
With 1-safe replication, the transactions are acknowledged immediately after they have been committed at the Primary. This offers significant performance gains. After the commit, the transactions are sent to the Secondary, in an asynchronous way. The trade-off is that, when a failure occurs at Primary, a few transactions that were in transfer, might be lost.
Either of the two replication methods can be chosen dynamically, or even per session or transaction. The replication delay that is involved with 1-safe replication can be controlled, too.
