MariaDB discusses database scale and active:active and active:passive architectures

Interview: We received a note from MariaDB summarizing the pros and cons of active:active and active:passive database architectures and realized we didn’t actually know much about this topic. That spurred us asking its Chief Product Officer, Vikas Mathur to provide information about the two.

Blocks & Files:Please describe active-passive database architecture, listing its advantages and its limitations.

Vikas Mathur: Active-passive is a high-availability deployment approach in which a primary database does all read/write operations, and one or more standby replicas continuously receive changes via synchronous or asynchronous replication. Synchronous replication ensures the primary waits for replica confirmation before committing transactions, guaranteeing zero data loss but introducing latency. Asynchronous replication allows the primary to commit immediately without waiting for replicas, improving performance but risking seconds to minutes of data loss if the primary fails before changes reach the standby.

The replicas remain idle until the primary database fails. When failure occurs, one replica must be promoted to become the new primary. Promotion is performed either manually, where administrators detect failures and execute promotion commands, or through managed failover, where automation tools handle detection and promotion.

MariaDB MaxScale is a database proxy that sits between applications and database servers that makes the failover transparent to the application layer. It continuously monitors database health, automatically detects primary failures within seconds, and promotes a standby replica. MaxScale also holds connections and replays transactions after the failover enabling zero down-time for the application.

The advantages of active-passive architectures are straightforward: operational complexity is low, the technology is mature and well tested after decades of production use, and no conflict resolution is required because only one database accepts writes at a time. Key disadvantages include wasted spending as replicas remain idle until needed, but downtime can be eliminated by using the right automation tools like MariaDB MaxScale.

Blocks & Files:Next, please explain active-active database architecture, listing its advantages and its limitations.

Vikas Mathur: Active-active database architectures are multiple database nodes operating simultaneously, with continuously synchronized data and traffic distributed across all nodes. It ensures that all the nodes can serve both read and write traffic (unlike active-passive architecture where a passive node is idle and not serving traffic).

However, synchronous replication typically increases write latency as all nodes need to acknowledge a commit. It can also lead to higher operational complexity due to conflicts for certain use cases, such as real-time inventory management, across regions. It is also sensitive to network latency between nodes and is more expensive to implement correctly.

There are variations of active-active architecture where writes are served by only the primary node while reads are spread across all replica nodes (sometimes spread across regions). This architecture can then be supported by asynchronous replication but requires the application to tolerate some lag between a write and a read of the same data tuple. Many enterprises use this version of active-active to maximize utilization of their hardware, achieve low write latency, while still achieving high availability, albeit with some minimal risk of data loss.

MariaDB Galera when clubbed with MaxScale provides an active-active solution for customers enabling full utilization of all nodes along with zero down-time failover. With MariaDB platform both flavors of active-active – synchronous and asynchronous can be achieved.

Blocks & Files:How does scale affect these limitations? Can you provide cost examples?

Vikas Mathur: By definition, active-passive architecture incurs higher cost as it requires standby replicas that don’t actively serve traffic. This exacerbates as the scale increases (both vertically with larger nodes and horizontally with more passive nodes in the standby cluster).

However, other limitations like scalability are more impacted by the type of replication used underneath the covers. Asynchronous replication scales read traffic horizontally very well but writes (concentrated in a single node) can only be scaled vertically by increasing the node size.

Synchronous replication technologies can double write traffic served by utilizing both active and passive nodes, but horizontal scaling is limited to a few nodes only as network latency between nodes slows down write performance.

Blocks & Files: Do you see customers progressing from active-passive to active-active as their database needs scale up? Can they migrate?

Vikas Mathur: We see organizations moving to active-active built on top of asynchronous replication (for example with MariaDB Maxscale) to achieve maximum utilization of their hardware (lower cost) and achieve full read scaling and zero downtime during failover.

Active-active as a whole is also growing because cloud-native applications, large e-commerce platforms, and real-time financial trading systems need instant data and order processing and lose business if the application is down even for a few seconds.

Full active-active built on synchronous replication is more complicated to setup and offers limited horizontal scalability, hence is adopted primarily in mission critical applications like payment processing.

Blocks & Files:How can you mitigate the disadvantages of active-active architecture, such as complexity, data consistency issues, limited vendor support, etc.?

Vikas Mathur: Built-in cluster management tools like MariaDB MaxScale reduce operational complexity significantly. Active-active architectures avoid data consistency problems when they employ synchronous internal replication, ensuring all nodes maintain identical data states. These high-availability solutions target enterprise deployments when downtime is unacceptable and performance demands are high.

Organizations that source their entire database stack from a single vendor benefit from unified support, eliminating the finger-pointing and integration issues common in multi-vendor environments.

Bootnote

A database proxy is an intermediate software layer (or server) that sits between client applications and one or more database servers, decoupling applications from the underlying database infrastructure. It intercepts, manages, routes, and sometimes transforms database requests to provide connection pooling and management, load balancing, read/write splitting, high availability and failover handling, query routing and rewriting, security enhancements, and observability and operations, such as logging, metrics, and sometimes query caching or transformation without changing application code.