Reference Architecture for MariaDB Galera Cluster

A MariaDB Galera Cluster is the recommended deployment for a scalable database server architecture, and this article outlines what it looks like, and what its benefits are. Following this reference architecture will result in a load-balanced cluster, with high-availability achieved through load-balancing.

The minimal size of a MariaDB Galera cluster is 3 nodes — one node can be taken out of rotation and be executed maintenance on, or fail, and return to the cluster while the other 2 nodes maintain quorum.

Further nodes increase the processing capacity of the cluster, but since all nodes are full replicas of one another, adding further nodes does not increase the storage capacity of the cluster.

This reference architecture uses HAProxy to distribute database client connections across the cluster. Since MariaDB entertains 3 aspects to authentication (source IP address(es), a username and a password), HAProxy should be configured as a transparent proxy — preserving the original source IP address for the connection. This therefore requires that the node that runs HAProxy instance is also a part of the route back from the server to the client.

For the purposes of this reference architecture, let the MariaDB Galera cluster nodes live in Network M. Let database clients live in Network C. Between networks C and M is a gateway (actually, at least one), which for Network M is also the ideal location for a load-balancer and transparent proxy. Read more about a redundant firewall setup.

NetworkIP Address SpaceGateway
Network C (database clients)192.168.2.0/24192.168.2.254
Network M (MariaDB Galera Cluster)192.168.3.0/24192.168.3.254

Clients in Network C would connect to MariaDB using the gateway address for Network M (192.168.3.254). HAProxy will be listening for new connections on 192.168.3.254:3306.

HAProxy is configured such that client connections are distributed across MariaDB Galera nodes by source IP address. This ensures that any one client uses the same target database server.

Topology for MariaDB Galera Cluster behind HAProxy

MariaDB Galera replication is not synchronous in the same way more traditional database technologies employ a two-phase commit. While the details of how MariaDB Galera implements replication are beyond the scope of this article, configuring the load-balancing as to be sticky on source is still recommended.

Note that applying NAT on the firewalls between the networks is sticky on source as well, but comes with the following downsides;

  • There is no health-check against the target nodes,
  • The target IP addresses need to be sequential,
  • The MariaDB Galera cluster nodes would require a service IP address in addition to the system IP address, maintained through something like keepalived,
  • A fail-over scenario unfairly balances connections — with 3 nodes, 2/3 would end up on one node, and 1/3 on the other node.

Similar challenges apply to employing round-robin DNS to let clients connect to the MariaDB Galera cluster;

  • The target node is never determined, since both the DNS server as well as the DNS client will randomize in which order the results for the DNS query are returned, and then used,
  • It builds a very hard dependency on replication being instantaneous, but transaction’s replication is non-blocking, and replication is not strictly synchronous,
  • The MariaDB Galera cluster nodes would require a service IP address in addition to the system IP address, maintained through something like keepalived,
  • A fail-over scenario unfairly balances connections — with 3 nodes, 2/3 would end up on one node, and 1/3 on the other node.

Furthermore, allowing the same client to hit the same MariaDB Galera cluster node will allow a more optimal use of query caches.

See Also

 

Posted in Documentation and tagged , , , , .