High Availability

Topics on This Page:

High Availability Solutions
Automatic Failover with MaxScale
Deploy MariaDB Enterprise Server with HA
Deploy MariaDB Xpand
Deploy MariaDB Community Server with HA

Enterprise applications often require the ability to run continuously for extended periods of time with little or no user-facing downtime.

High Availability Solutions

MariaDB Platform X5 supports several different high availability solutions.

MariaDB Replication

MariaDB Replication supports high availability.

Replica servers replicate data from a primary server asynchronously or semi-synchronously using binary logs. Upon primary server failure, a replica server can be promoted to a primary server.

Galera Cluster

Galera Cluster supports high availability.

Cluster nodes replicate data using certification-based replication implemented by the Galera 3 or Galera 4 plugin, depending on the version of MariaDB. Upon node failure, the cluster automatically recovers, as long as remaining nodes have quorum.

MariaDB Enterprise ColumnStore

MariaDB Enterprise ColumnStore supports high availability in multi-node deployments.

ColumnStore nodes share data using shared storage. Upon node failure, shared storage can still be accessed by remaining nodes.

MariaDB Xpand

MariaDB Xpand supports high availability.

Xpand divides tables and indexes into slices, and it distributes those slices among all the nodes. Xpand maintains replicas of each slice, so that it can recover from a node failure without loss of data.

It is available in two topologies:

MariaDB Xpand Performance topology delivers maximum throughput and lowest latency.

Xpand Storage Engine topology leverages Xpand's benefits and maximize compatibility with MariaDB Enterprise Server (ES). It allows Xpand users to leverage ES features like window functions, CTEs, and cross-engine JOINs.

For additional information, see "MariaDB Xpand Topologies".

Automatic Failover with MaxScale

MariaDB MaxScale augments MariaDB Platform's HA solutions with additional automatic failover capabilities. The specific capabilities depend on the high availability solution that is used:

HA Solution	Description
MariaDB Replication	MaxScale's MariaDB Monitor (mariadbmon) detects primary server failure and promotes the most up-to-date replica based on Global Transaction ID (GTID), waits for that replica to execute any transactions in its relay log, and begins routing queries to it.
Galera Cluster	MaxScale's Galera Monitor (galeramon) is used to minimize application impact upon server failure. Additionally, MaxScale may be used to assign primary and replica roles to database instances within a cluster to support read/write traffic splitting and to minimize the risk of certification failures.
MariaDB Enterprise ColumnStore	MaxScale's MariaDB Monitor (mariadbmon) determines which node is the primary server, and automatically performs failover upon primary server failure.
MariaDB Xpand Performance Topology	MaxScale's Xpand Monitor (`xpandmon`) determine which nodes are currently part of the deployment, and it only routes connections to nodes that are available.
MariaDB Xpand Storage Engine Topology	MaxScale's MariaDB Monitor (mariadbmon) determine which node is the primary server, and automatically performs failover upon primary server failure.

MaxScale's Read/Write Split Router (readwritesplit) includes several configurable features to minimize the impact of failover on client connections:

Feature	Description
Automatic Reconnection	Replaces back-end server connections to a failed server with connections to a different server, rather than closing the connections.
Transaction Replay	Ensures the execution of prior transactions before additional queries are routed to different Servers, instead of closing the connection and requiring the application to roll the transaction back and retry.
Connection Maintenance and Restore	Ensures all servers handling traffic for a connection have the same session system variables, user-defined variables, etc.
Read Retry	Allows MaxScale to route incomplete queries to a different replica rather than returning an error or closing the client connection.
Delayed Retry	Allows MaxScale to delay and retry write queries received after a primary fails and before automatic failover completes, rather than returning an error or closing the client connection

Deploy MariaDB Enterprise Server with HA

Choose an HA solution to deploy for MariaDB Enterprise Server:

HA Solution	ES Deployment	MaxScale Deployment
MariaDB Replication	Deploy a Primary Server with MariaDB Enterprise Server Deploy a Replica Server with MariaDB Enterprise Server	Deploy MaxScale with MariaDB Monitor and Read/Write Split Router Deploy MaxScale with MariaDB Monitor and Read Connection Router
Galera Cluster	Deploy an Enterprise Cluster Node with MariaDB Enterprise Server	Deploy MaxScale with Galera Monitor and Read/Write Split Router Deploy MaxScale with Galera Monitor and Read Connection Router
Multi-Node Enterprise ColumnStore	Deploy Multi-Node Enterprise ColumnStore	Included in ES Deployment Instructions
MariaDB Xpand Storage Engine topology	Deploy Xpand Storage Engine topology	Deploy MaxScale with MariaDB Monitor and Read/Write Split Router Deploy MaxScale with MariaDB Monitor and Read Connection Router

Deploy MariaDB Xpand

MariaDB Xpand provides distributed SQL, high availability, fault tolerance, write scaling, and horizontal scale-out for transactional workloads. It is available in a standalone topology and in a topology with MariaDB Enterprise Server using the Xpand storage engine. Both topologies support high availability.

To deploy MariaDB Xpand, choose a topology:

Topology	Description
Xpand Performance	Delivers maximum throughput and lowest latency. Uses MaxScale as a transparent database proxy to monitor node health and route queries to Xpand nodes. Xpand stores data in a distributed manner and executes queries using parallel query evaluation.
Xpand Storage Engine	Leverages Xpand's benefits and maximizes compatibility with MariaDB Enterprise Server (ES). Uses MaxScale as a transparent database proxy to monitor node health and route queries to ES nodes. ES nodes store non-Xpand tables and interact with Xpand tables using the Xpand Storage Engine. Xpand stores data for Xpand tables in a distributed manner and executes queries using parallel query evaluation.

Topology

Description

Xpand Performance

Delivers maximum throughput and lowest latency.
Uses MaxScale as a transparent database proxy to monitor node health and route queries to Xpand nodes.
Xpand stores data in a distributed manner and executes queries using parallel query evaluation.

Xpand Storage Engine

Leverages Xpand's benefits and maximizes compatibility with MariaDB Enterprise Server (ES).
Uses MaxScale as a transparent database proxy to monitor node health and route queries to ES nodes.
ES nodes store non-Xpand tables and interact with Xpand tables using the Xpand Storage Engine.
Xpand stores data for Xpand tables in a distributed manner and executes queries using parallel query evaluation.

For additional information, see "MariaDB Xpand Topologies" and "Deploy Xpand 5.3".

Deploy MariaDB Community Server with HA

Choose an HA solution to deploy for MariaDB Community Server:

HA Solution	ES Deployment	MaxScale Deployment
MariaDB Replication	Deploy a Primary Server with MariaDB Community Server Deploy a Replica Server with MariaDB Community Server	Deploy MaxScale with MariaDB Monitor and Read/Write Split Router Deploy MaxScale with MariaDB Monitor and Read Connection Router
Galera Cluster	Deploy a Galera Cluster Node with MariaDB Community Server	Deploy MaxScale with Galera Monitor and Read/Write Split Router Deploy MaxScale with Galera Monitor and Read Connection Router