High Availability and Scaling

Cluster options

Single-node cluster: A single-node cluster 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 cluster: A multi-node cluster 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.

Database scaling

You can scale the existing database clusters using "horizontal" and "vertical" scaling.

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 a cluster.

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 database performance.

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 a cluster 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 cluster, you may expect downtime before the Virtual Machine (VM) restarts because the node is modified in place.

Warning: The connection to the database 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.

Replication modes

The synchronization_mode determines how transactions are replicated between multiple nodes before a transaction is confirmed to the client. IONOS DBaaS supports only the asynchronous (default) replication mode for MariaDB, wherein the first transaction commit is always on the master, followed by replication to the standby node(s).

Asynchronous replication sends a transaction confirmation back to the user immediately after the transaction is written to disk on the primary node without waiting for the standby. Replication takes place in the background. The cluster can lose some committed (not yet replicated) transactions during a failover to a secondary node in an asynchronous mode. The performance penalty of asynchronous replication depends on the workload.

MariaDB uses an asynchronous replication mechanism. The primary node's binary log needs to be enabled to save data and make structural changes in the binary log. For more information, refer to the MariaDB Documentation.

Warning: You may lose your data if the server crashes while your data is pending replication.

Synchronization mode considerations

Please note that the synchronization mode can impact DBaaS in several ways:

Aspect	Asynchronous
Primary failure	A healthy standby will be promoted if the primary node becomes unavailable.
Standby failure	No effect on primary. Standby catches up once it is back online.
Consistency model	Strongly consistent except for lost data.
Data loss during failover	Non-replicated data is lost.
Data loss during primary storage failure	Non-replicated data is lost. Because replication is asynchronous, it is possible that the secondary primary has not yet received all events in the case that the active primary crashes.
Latency	Limited by the performance of the primary node.