High Availability and Scaling

In-Memory DB instances

  • Single-node instance: A single-node instance only has one "primary node". This node accepts customer connections and performs read and write operations. It is a single point of truth and a single point of failure.

  • Multi-node instance: A multi-node instance contains one "primary node" and one or more "secondary nodes" replicating data from the primary node. The secondary nodes always attempt to keep up-to-date with the primary, but they may lag due to the asynchronous replication. If the current primary node fails, a secondary node elevates to the primary node. The old primary node is automatically fixed and turned secondary.

Note: Scaling is not supported by a multi-node instance; it presently only offers high availability.

In-Memory DB instance scaling

You can scale the existing In-Memory DB instances using "horizontal" and "vertical" scaling.

Horizontal scaling is defined as configuring the number of nodes that run in parallel. You can increase or decrease the number of nodes in an instance.

Scaling up the number of nodes does not cause a disruption. However, decreasing may cause a switchover, if the current primary node is removed.

Note: This method of scaling is used to provide high availability. It will not increase the performance.

Replication modes for high availability

The synchronization_mode determines how transactions are replicated between multiple nodes before a transaction is confirmed to the client. IONOS DBaaS supports the following replication modes for In-Memory DB: Asynchronous (default) and Semi-Synchronous. In either mode, In-Memory DB commits the transaction first on the primary and then replicates to the standby secondary node(s).

Asynchronous replication

However, In-Memory DB has a built-in asynchronous replication mode, which does not wait for the standby before confirming a transaction back to the user. Transactions are confirmed to the client after being written to disk on the primary node. Replication takes place in the background. In asynchronous mode, the instance is allowed to lose some committed (not yet replicated) transactions during a failover to ensure availability.

The benefit of asynchronous replication is the lower latency. The downside is that recent transactions might be lost if standby is promoted to the primary node. The lag between the primary and secondary nodes tends to be a few milliseconds.

Semi-synchronous replication

For semi-synchronous replication, you can use the WAIT command. This is particularly useful to prevent data loss if the primary node goes down after acknowledging but before replicating the write operation. Executing the command blocks the client until all pending write operations are transferred and acknowledged by the specified replicas. For more information, refer to the In-Memory DB documentation.

Last updated