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.
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.
Vertical scaling refers to configuring the size of the individual nodes to process more data and queries. You can change the number of cores and the memory size to have the configuration you need.
During scaling, the existing nodes in an instance are modified after being turned off. In the event of scaling up or down, the downtime is minimal when there are multiple nodes, as the secondary nodes are modified first, followed by the resources. After the modification is complete, the primary node is switched automatically over to a secondary node and the connection is established.
For a single-node instance, you may expect downtime before the Virtual Machine (VM) restarts because the node is modified in place.
Warning: The connection to the In-Memory DB instance will be terminated if it is connected to an application. Additionally, all ongoing queries will be aborted causing disruption. Hence, we recommend that you perform scaling outside of peak hours.
You can also increase the size of storage. However, it is not possible to reduce the size of the storage, nor can you change the type of storage. Increasing the size is done on the fly and causes no disruption.
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).
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.
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.