> For the complete documentation index, see [llms.txt](https://docs.ionos.com/cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ionos.com/cloud/databases/in-memory-db/overview/high-availability-scaling.md).

# 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.

{% hint style="info" %}
**Note:** Scaling is not supported by a multi-node instance; it presently only offers high availability.
{% endhint %}

## In-Memory DB instance scaling

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

{% tabs %}
{% tab title="Horizontal 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.

{% hint style="info" %}
**Note:** This method of scaling is used to provide high availability. It will not increase the performance.
{% endhint %}
{% endtab %}

{% tab title="Vertical Scaling" %}
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 [<mark style="color:blue;">Virtual Machine (VM)</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#virtual-machine-vm) restarts because the node is modified in place.

{% hint style="warning" %}
**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.
{% endhint %}

You can also increase the size of storage. However, it is impossible 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.
{% endtab %}
{% endtabs %}

## Replication

Replication between the primary and secondary instances is always asynchronous and is not configurable. The primary instance commits a write and confirms it to the client without waiting for secondary nodes to acknowledge it; replication to secondaries happens in the background.

The benefit of asynchronous replication is lower latency, since the client does not wait on secondary acknowledgment. The trade-off is that recent, unreplicated transactions can be lost if a secondary is promoted to primary during a failover. The lag between the primary and secondary nodes is typically a few milliseconds.

{% hint style="info" %}
**Note:** Applications that need stronger durability guarantees can issue the [<mark style="color:blue;">`WAIT`</mark>](https://redis.io/docs/latest/commands/wait/) command from the client to block until a write has been acknowledged by a specified number of replicas. This is a client-side technique, not a replication setting configurable by <code class="expression">space.vars.ionos\_cloud</code>.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ionos.com/cloud/databases/in-memory-db/overview/high-availability-scaling.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.