How MariaDB Cloud Optimizes Database Resilience and Cost: A Deep Dive into High Availability

MariaDB has long been the backbone of mission-critical applications, valued for its rich feature set, developer-friendly SQL dialect and a massive global ecosystem of tools. But as workloads migrate to the cloud, the conversation has shifted from simple database features to operational excellence. Today, the priority is on seamless scaling, rock-solid security, effortless replication, and guaranteed uptime – all while finally delivering on the cloud’s promise of significant cost savings.

It is a common misconception that cloud database management is a “set it and forget it” problem. In reality, real world production environments undergo continuous changes, increasing the chances for failure. Hyperscaler offerings such as AWS RDS are restricted to a single cloud environment and lack access to the robust high-availability (HA) and multi-cloud disaster recovery (DR) strategies that modern enterprises require. MariaDB Cloud was designed to solve these challenges, supporting the top three clouds to ensure data remains resilient even if a specific cloud provider encounters a regional failure.

In this blog, we’ll delve into how MariaDB Cloud tackles these challenges.

What Are the Real Gaps in Cloud Database High Availability?

While virtually every cloud database solution touts high availability, this often does not translate into continuous availability. The transition from an active server to a standby can often take minutes or longer, resulting in prolonged disruptions which can be catastrophic for mission-critical applications.

To provide high resiliency, we protect every layer of the stack – disks, compute, zones/cloud regions, network, and even the load balancer accepting incoming DB connections.

All cloud databases configured for HA replicate data across multiple availability zones (AZ), ensuring your data is protected against data center failures. This is necessary, but not sufficient. In MariaDB Cloud, data is always isolated from compute on the underlying block storage device of each AZ. This device keeps a copy of each block on multiple servers, providing the first layer of protection against component failures or corruption.

The deployment of DB servers occurs within containers orchestrated by Kubernetes (k8s). In the event of cloud instance failures, MariaDB Cloud’s health monitoring prompts k8s to revive the container in an alternate instance, seamlessly reconnecting to the same storage volume. AWS RDS, for example, runs MariaDB on VMs, requiring a replicated setup for any protection against node failures.

While hardware failures are a possibility, a more common scenario involves a DB crash due to resource exhaustion or timeouts—such as running out of allocated temp space due to rogue queries or an unplanned large spike in data load. In such instances, it is crucial for application connections to smoothly transition to an alternate server.

Behind the scenes, MariaDB Cloud consistently directs SQL through its intelligent proxy, MariaDB MaxScale. This proxy not only continuously monitors servers for failures but also remains acutely aware of any replication lags in the “semi-synchronous” replica servers. Should a primary server fail, an immediate election process ensues to select a replica with the least lag. Simultaneously, any pending events are flushed, ensuring synchronization and full data consistency. Any pending transactions on the primary server are also replayed on the newly elected primary. Collectively, these measures enable applications to operate without connection-level interruptions or SQL exceptions. Achieving heightened levels of High Availability (HA) is effortlessly attainable by expanding the number of replicas. Replication can even extend across different cloud providers or to a self-managed replica within a customer’s own environment.

MariaDB Cloud also offers a Fully Synchronous option where all writes can be committed to replicas using Galera clustering. Unlike semi-synchronous replication, where MaxScale must monitor for replication lags, Galera ensures a transaction is only considered committed after passing write-set certification on all active nodes, guaranteeing no replica lag. When failures occur, reads and writes continue with zero delays or application impact.

In contrast, the high availability behavior in Google’s CloudSQL (MySQL) or AWS RDS (MariaDB) relies on a standby replica. When the active server encounters a failure, the standby is elevated to the position of the new active server. This transition is a time-consuming process — triggering “crash recovery”; often exceeding two minutes, and varying according to the nature of the failure. In MariaDB Cloud, failover on a server crash happens within a few seconds.

AWS RDS utilizes a DNS-based approach for failover, where the DNS record is updated to direct to the new primary instance. Moreover, application clients tend to cache DNS records and may not diligently adhere to the DNS TTL (time-to-live) configuration. The ultimate consequence often manifests as connection failures on the application client side, potentially leading to an outage.

How Does MariaDB Cloud Scale Concurrent Users Without Sacrificing Consistency?

Cloud offerings of open-source relational databases often achieve scalability by distributing data across a cluster of nodes, relying on a replication model where ‘writes’ to the primary node are asynchronously transmitted to one or more replicas. Typically, the onus is on the customer to manage the distribution of traffic across the cluster, either through client application logic or by configuring a proxy service. Several customers have told us that this is simply too big a challenge, effectively capping the scalability of these cloud solutions. Even when customers successfully navigate this challenge, with this approach data consistency might not be uniform across the entire cluster at any given moment.

When application client connections are evenly load balanced across these replicas for ‘reads,’ the application must either tolerate potentially stale reads or consistently direct all requests to the primary, severely limiting scalability. Replicas are relegated to offline tasks like reporting — a common scenario from our observations in AWS RDS.

Contrastingly, in MariaDB Cloud, MariaDB MaxScale maintains consistency without compromising its ability to load balance requests across replicas, supporting both ‘causal’ and ‘strong, global’ consistency models. This allows you to scale for concurrency without losing consistency.

Causal consistency ensures that ‘reads’ are fresh only concerning the writes they are causally dependent on. If the replicas lag behind, the sequence may be satisfied exclusively by the primary, while concurrent clients continue to be load balanced across all servers. To ensure consistent reads in modern distributed environments (microservices), awareness of global lag is imperative. This is seamlessly achieved with a simple switch in MariaDB Cloud.

Strict and Global Consistency — Developers also have the option to use Galera clustering for seamless active-active, multi-primary horizontal scaling. MaxScale maintains its role by providing application abstraction and intelligent routing, even allowing you to direct all write traffic to a single node to simplify application logic and proactively avoid write conflicts in prone environments. This topology is ideal for high-throughput OLTP systems and environments with strict data consistency requirements.

MariaDB Cloud achieves superior throughput and reduced latencies compared to the standby replica approach in RDS or GCP CloudSQL. Unlike those services, where the standby is typically unused (wasting resources), MariaDB Cloud maximizes the available compute power across all nodes, delivering unparalleled cost-effectiveness.

A notable feature is Read-Write Splitting, allowing for custom routing. For example, point queries can be directed to specific nodes, while resource-intensive reporting scans can be routed to a separate set of nodes. This is easily implemented through standard SQL comments known as “Hint Filters.”

How Does MariaDB Cloud Handle Disaster Recovery Across Regions and Cloud Providers?

Major cloud providers tout disaster recovery across regions, but technical issues impacting an entire region for a specific provider (like DNS-level failures) are more common than natural disasters.

One effective strategy to mitigate such risks is to replicate data to a data center owned by a different cloud provider within the same geographical area, minimizing network latencies. Disaster recovery across cloud providers is of course something an individual provider such as AWS or GCP simply can’t support. Alternatively, customers can maintain their own “standby” database for emergencies—an environment entirely under their control, ensuring a near-real time copy of the data at all times. MariaDB Cloud empowers users to configure “external” replicas that can run anywhere, offering flexibility and resilience.

To facilitate this, MariaDB Cloud provides several built-in stored procedures for configuring both “outbound” and “inbound” replication to any compatible MariaDB server environment. This flexibility allows users to tailor their disaster recovery strategy based on their specific needs, whether replicating across regions, cloud providers, or maintaining self-managed standby environments.

One can also use the MariaDB Cloud built-in Backup service to schedule continuous incremental backups (say every hour) to a customer-owned S3 bucket, essentially ensuring a “peace of mind” backup and providing a separate, resilient copy of your data even in the extremely unlikely event of an entire service failure.

How Does MariaDB Cloud Auto-Scale for Cost Optimization?

Often, the default strategy involves over-provisioning based on peak usage. Unlike AWS RDS MariaDB, which only offers storage autoscaling, MariaDB Cloud offers advanced auto-scaling capabilities for both compute and storage.

MariaDB Cloud’s auto-scaling is guided by practical database management principles. It continually monitors concurrent active sessions, CPU utilization, and disk usage. Rather than reacting impulsively to short-term spikes, the system predicts sustained patterns.

If the system anticipates a surge will push the current instance type to its limit, MariaDB Cloud automatically scales up. When demand subsides, it scales down. By enabling customers to pay solely for their actual consumption, this feature yields significant cost savings compared to operating a self-managed MariaDB community server on the cloud.

Get Started with MariaDB Cloud

We’ve highlighted how MariaDB Cloud provides unique resilience and optimizes costs through auto-scaling. Our commitment to excellence is unwavering as we continue to lead the market in reliability and innovation.

We encourage you to witness the difference firsthand. Try MariaDB Cloud and tell us what you think.

Frequently Asked Questions