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.

In-Memory DB instance scaling

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

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.

Features

• In-memory data structure store: In-Memory DB can be used as a data structure, cache, message broker, and streaming engine.

• Multiple data types and structures: While technically In-Memory DB is a key-value store, it is also a data structure server that supports multiple data types and structures, including the following: strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes, and streams.

• Key eviction policy: In-Memory DB supports LRU key eviction policy, which automatically detects old data in the cache when the maxmemory limit is reached upon incorporating new data. For more information, refer to the .

• Lua Scripts: You can upload and execute Lua scripts to the In-Memory DB server. These scripts can use programmatic control structures and supported commands to access the In-Memory DB instance during execution.

• Built-in asynchronous replication: Its built-in asynchronous replication feature acknowledges the amount of data processed. For more information, refer to the .

• On-disk persistence: It persists data on disks using AOF and RDB persistence options.

• User Management and Security: Access to the instance can be restricted to authorized users only. Role-based access control, robust encryption support, and user management tools ensure secure access and data protection.

IONOS DBaaS Features

• Upgrades: IONOS DBaaS supports user-defined maintenance windows with minimal service disruption. The In-Memory DB instance may be unreachable for a few seconds when necessary for restarts or switching to another replica. Single-node instances temporarily gain a second node when it is necessary to replace the old one. Hence, maintenance downtime is the same for multi-node and single-node instances.

• Programmatic Resource Management: Easier to deploy and manage In-Memory DB in the IONOS Cloud ecosystem through APIs, SDKs, and configuration management tools.

• Monitoring and Reporting: In-Memory DB provides tools for performance monitoring, query analysis, and reporting to help optimize instance usage and identify potential issues.

• Restore backup files: You can restore the backup files of each In-Memory DB cluster. For more information, see .

Benefits

• Easy Configuration: Configure your In-Memory DB instance to comply with IONOS DBaaS's specifications. You can quickly create an instance and define users using the API commands.

• Swift data retrieval: Its in-memory data structure store allows quick data retrieval from the cache.

• Scalable: Because of In-Memory DB's vertical scalability, you can add storage, memory, and cores to match the growing demand for greater data processing power.

• High availability: It supports both multi-node and single-node instances, which are equipped with automatic node failure handling. This ensures that it can continue to operate smoothly even if one or more nodes fail.

• Security: If your In-Memory DB instance is configured to use TLS, clients and In-Memory DB communicate securely using TLS. For more information, refer to the following sections of the In-Memory DB documentation:
• Resources: It is offered on Enterprise VM, with a dedicated CPU, storage, and RAM. Currently, SSD is the only supported storage option for In-Memory DB.

• Network: To guard against direct internet-based threats, DBaaS is only connected to private networks.

IONOS Cloud updates and patches your In-Memory DB instance to achieve high standards of functionality and security. This includes minor patches for In-Memory DB and patches for the underlying operating system. Generally, these updates are unnoticeable and do not interrupt your operation. However, occasionally, IONOS restarts your In-Memory DB instance to allow the changes to take effect.

Prerequisites

• Prepare for a downtime during the version upgrade.

• Ensure the instance has enough available storage. While the upgrade is space-efficient (because it does not copy the data directory), some temporary data is written to the disk.

Currently, IONOS DBaaS only supports minor upgrades for In-Memory DB. All changes that may cause service interruption (like upgrades) are executed within the maintenance window, which is a weekly four-hour window. During the maintenance window, you may experience uncontrolled disconnections and an inability to connect to the In-Memory DB instance. Such disconnections are destructive for any ongoing transactions and we recommend that you reconnect.

You can configure a maintenance window during the In-Memory DB instance creation using the same API request. For more information, see Create an In-Memory DB Instance. You can also configure one when you modify the existing In-Memory DB instance. For more information, see Modify an In-Memory DB Instance.

The following code schedules automatic maintenance every Monday at 16:30:59:

"maintenanceWindow":{
         "time":"16:30:59",
         "dayOfTheWeek":"Monday"
      },

Switchover process

For administrative reasons, automatic switchovers happen in a controlled, planned manner during the scheduled maintenance. However, data is preserved during a switchover.

During a switchover, the IP address of the primary server is moved to the promoted replica server. Meanwhile, the client is signaled about the switchover by closing the TCP connection on the server. The client automatically closes the connection and reconnects to the In-Memory DB instance.

Failover process

IONOS DBaaS for In-Memory DB has an automatic failover enabled by default. A failover can occur when the primary node fails. As a result, one of the replicas is chosen and promoted to be the new primary node. When the old primary node returns, it is added as a replica of the instance.

The following are a few limitations that you can encounter while using In-Memory DB:

• You cannot use multiple In-Memory DB instances simultaneously, but each for a particular use case.

• You have access to ten default In-Memory DB instances, which are numbered to differentiate them. However, it is not possible to add or rename the instances after creation.

• The total upper limit for CPU cores depends on your quota. A single instance cannot exceed 16 cores.

• The total upper limit for RAM depends on your quota. A single instance cannot exceed 32 GB.

• The upper limit for storage size is 2 TB.

• Storing In-Memory DB instance backups in an IONOS S3 Object Storage is limited to the last seven days.

• The following IP ranges cannot be used with In-Memory DB services:

  • 10.208.0.0/12

  • 10.233.0.0/18

  • 192.168.230.0/24

  • 10.233.64.0/18

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.

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.

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.

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

In-Memory DB is a key-value structure-based in-memory data storage. Data is stored in Random-Access Memory (RAM) instead of a disk and is swiftly accessible. Rapid access to data is provided by RAM, as opposed to a disk.

IONOS DBaaS for In-Memory DB is a fully managed service, compatible with legacy Redis® OSS, that gives you access to the capabilities of its data structures. It can be used as a dedicated in-memory cache and a real-time database service. This combination of services enables In-Memory DB to deliver greater performance.

It is simpler to configure your In-Memory DB instance with IONOS DBaaS. You get access to a secure, dedicated In-Memory DB server managed by IONOS. DBaaS gives you access to the capabilities of the In-Memory DB data structures, which means that you can use the same code, applications, and tools you already use in your existing databases. You can use the In-Memory DB features, such as patching the In-Memory DB data structures, creating backups and redundancy, and enhancing security with IONOS DBaaS.

When used as a cache, In-Memory DB accelerates data access from primary instances and associated data stores with minimal latency. This is quicker as compared to interacting with a traditional database. In-Memory DB acts as a caching layer, thus, speeding up the API response time and data retrieval.

In-Memory DB supports data persistence by writing data into long-lasting storage. For more information, see Data Persistence.

It is mandatory to specify a periodic maintenance time window for regular maintenance. During the maintenance time window, you may encounter a short, occasional downtime, typically caused by restarting In-Memory DB or switching to another replica.

Provisioning a new In-Memory DB instance via a fully managed IONOS DBaaS is faster than self-managed manual procurement, configuration, and installation of In-Memory DB on local hardware. Software patching and upgrades are performed automatically by DBaaS.

The illustration shows how In-Memory DB instances can be created and managed using IONOS DBaaS.

As shown in the illustration, you can order and manage an In-Memory DB instance using the API. Simultaneously, you can choose the LAN, VDC, and IP address on which In-Memory DB must be available. The IONOS Cloud DBaaS Backend provisions the In-Memory DB instance according to your request. The primary In-Memory DB instance will be available on your LAN within the VDC and on the chosen IP address after provisioning.

Supported versions

In-Memory DB is compatible with legacy Redis® OSS stable version 7.2.

The IONOS Cloud DBaaS takes care of minor version upgrades during maintenance windows. For more information, see Upgrade and Maintenance.

Locations

DBaaS for In-Memory DB is offered in all IONOS Cloud locations. You can use DBaaS instances running In-Memory DB in the IONOS Cloud infrastructure.

Security

The communication between clients and In-Memory DB is secured using TLS for secure data transmission if your In-Memory DB is set up to use it. For more information about enabling TLS, refer to the In-Memory DB documentation.

You get access to all command categories, except the commands that are listed in the "dangerous" category. For more information, refer to the .

DBaaS services offered by IONOS Cloud

All back-end tasks necessary to keep your In-Memory DB instance operating at peak efficiency are handled by the IONOS platform. You can perform the following:

• Pre-set instance configuration and configuration management options.

• Automated backups for seven days.

• Regular patches and upgrades during maintenance.

• Disaster recovery via automated backup only if persistence is configured. For more information, see .

• Service monitoring both for the In-Memory DB instance and the underlying infrastructure.

Administration

Tasks related to the optimal health of the In-Memory DB instance remain your responsibility. These include:

• Optimization

• Organizing data

• Updating statistics

IONOS DBaaS for In-Memory DB supports automatic backups. Automatic backups are created in either of the following instances:

• During the creation of an In-Memory DB instance.

• Upon upgrading the current version of In-Memory DB to a higher version.

IONOS DBaaS performs automatic daily full backups of the In-Memory DB instances that run regularly at a specific hour based on the value set in the DBaaS component. It ensures that there is a backup available for each day. IONOS maintains backups for the last seven days so that you can recover them for up to a week. For more information about backup restoration, see .