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

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:

AspectAsynchronous

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.

Last updated