The durability level controls how solidDB® handles transaction logging. The solidDB® server supports three durability levels: strict (safe), relaxed (fast), and adaptive. Relaxed durability yields best performance while strict durability minimizes loss of transactions. The adaptive durability level is available only in HotStandby configurations.
▪Strict durability: If a transaction is written to the transaction logs as soon as the transaction is committed, this is called “strict durability”. This type of durability maximizes safety.
▪Relaxed durability: If the server is permitted to defer the transaction write until the server is less busy, or until it can write multiple transactions together, this is called “relaxed durability” (or “relaxed logging”). If you use relaxed durability in a server that is not part of an HSB pair, you risk losing the most recent few transactions if the server terminates abnormally. If the server is part of an HSB pair, however, a copy of the transaction is on the other server (the Secondary). Also, even if the Primary server fails before it has logged the transaction, the transaction is not lost. Thus, when relaxed durability is used with HSB, relaxed durability causes little reduction in safety. Relaxed durability can also improve the performance of the system, especially in situations where the server load consists of many small write transactions.
▪Adaptive durability: Adaptive durability applies only to HotStandby Primary servers. Adaptive durability means that if the server is in Primary Active state (sending transactions to the Secondary), it uses relaxed durability. In any other state, strict durability is used. This gives you high performance (with little loss of safety) when HSB is active, yet maintains high safety if only one server is operating. Adaptive durability can be enabled effectively only when the 2-Safe replication is used (default).
Adaptive durability can significantly increase performance while it provides a high degree of data safety in failure situations. It can increase overall system throughput and it can reduce latency, that is, the time the user must wait before being told that the transaction has committed.
The durability level can be set as a server default with the Logging.DurabilityLevel parameter, or per session or transaction with the SET [TRANSACTION] DURABILITY statements.
Regarding replication protocols, STRICT corresponds to 2-safe and RELAXED to 1‑safe.
1-safe replication
With 1-safe replication, the commit statement is acknowledged immediately after the commit processing is completed at the Primary. The committed transaction is transmitted to the secondary asynchronously, after the control has been returned to the application.
The delay in transmitting the transaction can range from few milliseconds to a few hundred milliseconds. 1-safe replication offers significant performance gains because the latencies are reduced dramatically at Primary. The downside of 1-safe is that, in the case of a failure, a few transactions can be lost in a failover.
You can set the 1-safe replication for the server with the parameter HotStandby.SafenessLevel=1safe. Possible values of the HotStandby.SafenessLevel parameter are 1safe, 2safe, and auto; default is 2safe.
You can also control the safeness level dynamically with the SET commands:
SET SAFENESS {1SAFE| 2SAFE| DEFAULT}
SET SAFENESS sets the safeness level for the current session, until it is changed. SET TRANSACTION SAFENESS {1SAFE| 2SAFE| DEFAULT}
SET TRANSACTION SAFENESS sets the safeness level for the current transaction. After commit, the safeness level returns to the value set for the session, or the startup value, or the system default (which is 2-safe).
The option DEFAULT denotes the current setting for the session.
If the HotStandby.SafenessLevelparameter is set to auto(that is, “automatic”), you can control the safeness level with the programmatic durability controls (such as, SET DURABILITY RELAXED).
2-safe acknowledgement policy
When the 2-safe replication is enabled (default), the Primary server does not tell the client that the transaction has been successfully committed until the Primary receives acknowledgement that the Secondary has the transaction.
There are three different acknowledgement policies:
▪2-safe received: The Secondary server sends acknowledgement when it receives the data (default).
▪2-safe visible: The Secondary has updated its copy of the data, and the change is now visible. In other words, a client application that is connected to the Secondary server would be able to see the update.
▪2-safe durable: The Secondary server acknowledges when it has made the data durable, that is, when it has committed the data and written the data to the disk.
Choosing the 2-safe acknowledgement policy
2-safe received is faster. 2-safe durable is safer. Because the acknowledgement policies apply only when the Primary and Secondary server are both active (that is, both are applying the transactions), even 2-safe received is considered safe. You risk losing transactions only if both servers fail practically simultaneously (within a second of each other).
Using 2-safe received reduces latency (the amount of time between the start of the commit and the time that the user receives confirmation of the commit). The 2-safe received policy has little impact on overall throughput.