These durability options do not apply to In-Memory tables. See In-Memory Tables for additional information.
ClustrixDB offers the option to increase performance by specifying how transactions are committed and made durable. The user may specify the point during the commit process when the application is to be notified of a successful transaction commit.
ClustrixDB will work to ultimately make every transaction fully durable. Configuring these Durability Options allows the operator to request early reporting for a transaction. See diagram below to see how node failures can impact durability.
The default is for ClustrixDB to make its data durable and for the database to communicate a successful commit only after a transaction has been flushed to permanent storage. A transaction that has been reported as committed will be preserved, even in the event of an outage.
Optionally, ClustrixDB can return a success indicator prior to the records being fully committed and written to storage disk. This early Durability Reporting can provide a significant boost in throughput for low-value transactions as the transactions do not need to wait for disk. The risk of this early reporting is that transactions that have not been fully flushed to disk may be lost if a failure or outage occurs.
tx_sync_commit is the variable that determines when a user is informed of a transaction’s status as it traverses the Durability/Commit Process. It may be set globally or at the session level. For example, the system global tx_sync_commit can be set to STRICT while sessions running low-value, batched inserts could be set to RELAXED to ensure the inserts occur as quickly as possible
To set the value, use the following syntax:
SET [GLOBAL | SESSION] tx_sync_commit = desired value
The allowable values for tx_sync_commit are:
|RELAXED||The transaction has been prepared and logged to memory. Ideal for transactions where full durability is not essential.||Transaction loss is possible during a group change, node power loss, and hard node failure.|
|SEMISTRICT||The transaction has been prepared and logged to disk.||Transaction loss possible only with a multi-node outage.|
|STRICT (Default)||The transaction has been committed and written to disk.||None. Tolerates complete cluster outage.|
This diagram correlates the three possible durability reporting values with each progressive phase of the Durability/Commit process.