Chris standing up holding his daughter Elva

MariaDB Enterprise Cluster

Datasheet

01
Introduction

MariaDB Enterprise Cluster offers a multi-primary (active-active) cluster solution for MariaDB, providing high availability, read/write scalability and true synchronous replication. This means any node can handle read and write operations, with changes instantly replicated to all other nodes, ensuring no replica lag and no lost transactions.

MariaDB Enterprise Cluster requires at least three nodes to avoid split-brain situations. All nodes must be able to communicate with each other over specified ports, and low latency between nodes is ideal. To maintain accurate time tracking, all nodes must use the same network time protocol to be correctly synchronized.
MariaDB MaxScale plays a crucial role in an enterprise cluster, as it transparently abstracts complexity while ensuring scalability, high availability and security to the application. In a mission-critical cluster of five nodes, the application first communicates with MariaDB MaxScale, which sends the initial transaction to a node in the cluster. That node processes the transaction through the write set, which it replicates to the other nodes in the cluster using the wsrep API. Once the other nodes have processed and acknowledged the transaction, it is committed to all nodes.

Synchronous replication across all cluster nodes

02
Features of MariaDB
Enterprise Cluster

Multi-master

MariaDB Enterprise Cluster is a multi-master system, as all nodes can accept read and write operations and synchronize to ensure data consistency across all nodes.

Fault Tolerant

If one or more MariaDB Enterprise Server nodes in the cluster fail, the remaining nodes continue to operate. Additionally, the failed nodes are automatically taken offline, repaired and reintroduced into the cluster without intervention at the application level.

Geographically Distributed Data

Replicated nodes can be placed across a wide area network (WAN), and, combined with asynchronous replication, improve performance and reduce response times for end-user web services.

Security

By default, Enterprise Cluster replicates data between nodes using SSL. Enterprise Cluster allows you to encrypt replication data in transit using the Transport Layer Security (TLS) protocol. Enterprise Cluster also supports data-at-rest encryption, including the gcache file, the MariaDB Enterprise Cluster transaction log used for Incremental State Transfer (IST).

03
How It Works

Enterprise replication works through the following processes:

Write Set Broadcasting

When a client commits a transaction on any node in the cluster, that node, identified as the donor for that transaction, captures the changes in the write set associated with it. This write set is then broadcast to all other nodes in the cluster.

Certification and Application

Each receiving node runs a certification test to ensure that the incoming write set does not conflict with any concurrently committed local transactions.
If the write set passes certification, it is applied to the local database and the transaction is committed on that node.

Alternatively, if a conflict is detected, the conflicting transaction, which is usually the one executed locally, is aborted, ensuring data consistency across the cluster.

Virtually Synchronous

Virtually synchronous means that the commit order is globally consistent and all successful transactions are guaranteed to be applied on all active nodes, even though the actual data application might occur slightly after the commit on the initiating node. A transaction is not truly considered committed until it has passed certification on all nodes.

wsrep API

This API defines the interface between the replication library, known as the wsrep provider and the MariaDB database server. The API allows the database to expose hooks to capture and apply transaction write sets.

04
Role of MariaDB MaxScale

In combination with MariaDB MaxScale, Enterprise Cluster provides high availability, scalability and automated failover for mission-critical transactional workloads. MariaDB Enterprise Cluster provides parallel replication and data consistency across all nodes, automatically managing the identification and removal of failed nodes, as well as recovering and rejoining new nodes.

05
Use Cases

High Availability (HA) Mission-Critical Applications

A core strength of MariaDB Enterprise Cluster is its synchronous replication, ensuring that data is written to all nodes simultaneously. This makes it ideal for applications where data loss is unacceptable and downtime must be kept to a minimum.

Financial Trading Platforms: Systems requiring immediate data consistency across all read/write operations and where a server failure cannot result in lost transactions.
E-commerce and Online Retail: Ensuring inventory levels, shopping carts, and order status are immediately consistent across all user sessions, even during node failures.
Billing and CRM Systems: Applications where customer data and billing records must be instantly up-to-date and continuously available 24/7.

Continuous Operations Environments: Organizations with strict SLAs that prohibit maintenance windows.
Database Scaling and Infrastructure Changes: Adding or removing cluster nodes (scaling out or in) without interrupting service to the application.

Zero-Downtime Maintenance and Upgrades

MariaDB Enterprise Cluster supports rolling restarts of cluster members. By taking one node down at a time, performing maintenance (such as operating system patches or MariaDB version upgrades), and bringing it back up, the cluster remains operational throughout the process.

Disaster Recovery and Geo-Redundancy

MariaDB Enterprise Cluster can be deployed across multiple physical locations (data centers or availability zones), providing a robust disaster recovery solution that survives the complete loss of a site.

Multi-Data Center Deployment: Deploying a cluster across three or more geographically separated data centers to ensure regional failure resilience (requires sufficient low-latency network connectivity).
Disaster Recovery Setup: Deploying one cluster in a data center using asynchronous replication to a second cluster or a single node in a geographically separated data center for disaster recovery or failover to the second data center.

Load Balanced Read/Write Traffic: Using MaxScale’s Read/Write Split Router in front of the cluster to direct reads to any node and writes to a designated Primary node (or across multiple nodes if applications manage potential deadlocks).
High-Volume Write Environments: Suitable for applications with a high volume of concurrent write operations that need to be distributed across multiple servers for improved I/O capacity. However, users must be aware of potential certification failures (deadlocks) in highly contended environments.

Scaling Out Write Workloads

While synchronous replication adds some overhead, MariaDB Enterprise Cluster fundamentally allows any node to accept write queries. This can be combined with a proxy like MaxScale to effectively distribute traffic.

06
About MariaDB

MariaDB seeks to eliminate the constraints and complexity of proprietary databases, enabling organizations to reinvest in what matters most – rapidly developing innovative, customer-facing applications. Enterprises can depend on a single complete database for all their needs, that can be deployed in minutes for transactional, analytical and hybrid use cases. Trusted by organizations such as Deutsche Bank, DBS Bank, ServiceNow and Samsung – MariaDB delivers customer value without the financial burden of legacy database providers. For more information, please visit mariadb.com.