Data Persistence

In-Memory DB supports various persistence options. For more information, refer to the In-Memory DB documentation.

IONOS DBaaS completely supports a requirements-based persistence mechanism for In-Memory DB. You can either choose to use In-Memory DB (RDB) and Append-Only File (AOF) data persistence options or combine both for durable storage. Contextually, data persistence refers to the information saved on a reliable non-volatile storage medium (for example, memory, HDD, or SSD) that can be recovered even during a system failure. Hence, persistent data—or non-volatile storage—can save data that is still accessible even during a crash.

Note: To ensure the safety of your data during failures or maintenance, we strongly recommend using either RDB and AOF or one of the following persistence mechanisms so that In-Memory DB transfers the whole dataset to the disk.

RDB

An RDB is a compact single file called a snapshot, representing your In-Memory DB data in a binary format. Due to its compactness, storage of In-Memory DB data is quicker, and retrieval is swifter. IONOS DBaaS periodically writes In-Memory DB in-memory data to disk files with the .rdb file extensions, thus creating multiple snapshot files for each write operation. In-Memory DB writes the entire point-in-time view of the dataset to the persistent storage.

The default RDB settings for snapshots are as follows:

• every one hour for a single change or write operation.

• every five minutes for at least 100 write operations.

• every minute for at least 10000 write operations.

DBaaS clears In-Memory DB in-memory data soon after creating a snapshot on the disk. Because it is automated and periodic, the write operation will lessen your workload and resume activities quickly in case of a failure. During a system crash, you can select from multiple snapshot files stack and restore the appropriate version. You can also back it up to a S3 bucket.

Note: The disadvantage of this method is that you may lose data in the event of a failure because snapshots are saved at regular intervals.

AOF

In-Memory DB provides another data persistence option called the AOF, which logs all its data into a log file. Every time In-Memory DB performs a write operation, it appends it to the AOF file. The AOF file is saved with a .aof extension and can be used to recover the entire replicaset in case of a crash. You can use the file to reconstruct the original dataset during a server restart.

In-Memory DB automatically rewrites an AOF file in the background when it reaches its maximum capacity, compacting it to save just the most recent data version.

Benefits of RDB and AOF combination

• Regular backups of the In-Memory DB dataset.

• Secondary instances can use the RDB and AOF files to rebuild the dataset from the primary instance during replication.

• The restart time is faster than recreating the dataset from scratch, thus enhancing the performance, scalability, and reliability.

Determine Provisioned Block Storage in an In-Memory DB Cluster

The provisioned Block Storage in an In-Memory DB cluster depends on the amount of RAM configured and the data persistence mode selected.

Note: A minimum storage of 10 GB is applied for all data persistence modes in each node.

The amount of provisioned Block Storage is based on the relationship below:

Note:

• The RAM specified in the relationship table below refers to the Dedicated Core RAM.

• The total RAM is also determined by the number of nodes in your In-Memory DB cluster.

Data Persistence	Storage
None	1 x RAM
RDB	2 x RAM
AOF	4 x RAM
RDB & AOF	8 x RAM