An instance of Galera Cluster consists of a series of nodes, preferably three or more. Each node is an instance of MySQL or MariaDB that you convert to Galera Cluster, allowing you to use that node as a cluster base.
Galera Cluster provides synchronous multi-master replication, meaning that you can think of the cluster as a single database server that listens through many interfaces. To give you with an idea of what Galera Cluster is capable of, consider a typical n-tier application and the various benefits that would come from deploying it with Galera Cluster.
In the typical n-tier application cluster without database clustering, there is no concern for database replication or synchronization.
Internet traffic filters down to your application servers, all of which read and write from the same DBMS server. Given that the upper tiers usually remain stateless, you can start up as many instances as you need to meet the demand from the internet as each instance in turn stores its data in the data tier.
This solution is simple and easy to manage, but suffers a particular weakness in the data tier’s lack of redundancy.
For example, should for any reason the DBMS server become unavailable, your application also becomes unavailable. This is the same whether the server crashes or if you need to take it down for maintenance.
Similarly, this deployment also introduces performance concerns. While you can start as many instances as you need to meet the demands on your web and application servers, they can only put so much load on the DBMS server before the load begins to slow down the experience for end users.
In the typical n-tier application cluster you can avoid the performance bottleneck by building a whole stack cluster.
Internet traffic filters down to the application server, which stores data on its own dedicated DBMS server. Galera Cluster then replicates the data through to the cluster, ensuring that it remains synchronous.
This solution is simple and easy to manage, especially if you can install the whole stack of each node on one physical machine. The direct connection from the application tier to the data tier ensures low latency.
There are, however, certain disadvantages to whole stack clustering:
Despite the disadvantages, however, this setup can prove very usable for several applications. It depends on your needs.
To compensate for the shortcomings in whole stack clusters, you can cluster the data tier separate from your web and application servers.
Here, the DBMS servers form a cluster distinct from your n-tier application cluster. The application servers treat the database cluster as a single virtual server, making their calls through load balancers to the data tier.
In a data tier cluster, the failure of one node does not effect the rest of the cluster. Furthermore, resources are consolidated better and the setup is flexible. That is, you can assign nodes different roles using intelligent load balancing.
There are, however, certain disadvantages to consider in data tier clustering:
One solution to the limitations of data tier clustering is to deploy them with distributed load balancing. This scheme roughly follows the standard data tier cluster, but includes a dedicated load balancer installed on each application server.
In this deployment, the load balancer is no longer a single point of failure. Furthermore, the load balancer scales with the application cluster and thus is unlikely to become a bottleneck. Additionally, it keeps down the client-server communications latency.
Data tier clustering with distributed load balancing has the following disadvantage:
In addition to these deployment schemes, you also have the option of a hybrid setup that integrates whole stack and data tier clustering by aggregating several application stacks around single DBMS servers.
This scheme improves on the resource utilization of the whole stack cluster while maintaining it’s relative simplicity and direct DBMS connection benefits. It is also how a data tier cluster with distributed load balancing with look if you were to use only one DBMS server per datacenter.
The aggregated stack cluster is a good setup for sites that are not very big, but still are hosted at more than one datacenter.