MariaDB Cluster Admin Deep Dive
Database Training Architect II
In this course we will discuss the Galera write-set replication technology as implemented on MariaDB and CentOS 7. We will discuss the architecture and installation of MariaDB Galera Cluster. We will also discuss using the Galera Load Balancer and several cluster use-cases.
About the Course
This course will discuss the Galera write set replication technology as implemented on MariaDB and CentOS 7.
Prerequisites for This Course
This course assumes some basic Linux skills. Students may find these course useful in coming up to speed or refreshing their Linux skills.LPI Linux Essentials Certification Red Hat Certified System Administrator (EX200) - RHCSA Exam PrepStudents who are unfamiliar with MySQL or SQL in general should review a basic course.Database Administration and SQL Language Basics
What Is High Availability?
High availability is a characteristic of a system, which aims to ensure an agreed level of operational performance, usually uptime, for a higher than normal period.
MariaDB Galera Cluster Architecture
The MariaDB Server
The foundation of the MariaDB Galera Cluster, MariaDB, is a MySQL compatible DBMS released under the GNU General Public License, version 2. Created in the wake of Oracle's acquisition of Sun (and MySQL), the goal of the MariaDBS project is to be a free, open source drop-in replacement for MySQL. This is accomplished with library binary parity and exact matching with MySQL APIs and commands.
The wsrep Patch
The wsrep patch for MariaDB/MySQL was developed by Codership to impliment write-set replication through group communication on GNU/Linux systems.
The Galera wsrep Provider Library
The Galera Replication Plugin implements the wsrep API. It operates as the wsrep Provider and consists of the following layers:Certification Layer: This layer prepares the write-sets and performs the certification checks on them, ensuring that they can be applied. Replication Layer: This layer manages the replication protocol and provides the total ordering capability. Group Communication Framework: This layer provides a plugin architecture for the various group communication systems.
Installing MariaDB Galera Cluster
Installing the Packages
Starting with the 10.1 release of Mariadb, the wsrep patch is included in the server packages. This demonstration uses CentOS 7 on x86_64. If you're using a different distrubution, see here:https://downloads.mariadb.org/mariadb/repositories/#mirror=rackspace
Bootstrapping the New Cluster
After installing the packages and configuring the firewall and SELinux, it is time to bootstrap the cluster. This will create a new cluster that other nodes can be added to.
Adding Nodes to the Cluster
Once a new cluster has been bootstrapped, it is time to add nodes to the cluster. This same process can be repeated to add multiple nodes to the cluster.
Galera Load Balancer
The Galera Load Balancer supports several balancing policies that determine how incomming connections will be distributed.
The Galera Load Balancer listens on port 4444 for runtime managment commands. These commands can be used to add or remove nodes from the load balancer and to view connection stats.
By default the Galera Load Balancer only checks for the avaiablity of a TCP connection. This is insufficent for database connections. The watchdog functionality can be used for more extensive tests.
MariaDB Galera Cluster Use Cases
Implementing a Primary-Replica Cluster
In a primary-replica cluster, all writes are sent to one node known as the primary. Read-only queries may be sent to a replica node. The replica node can be useful for generating reports or running other long running queries that can effect the performance of the primary node. In MariaDB Galera cluster, all nodes are writable so there is no difference between the primary and replica node.
Implementing a Write-Scalable Cluster
In a write-scalable cluster, adding mode nodes distributes the writes across the cluster, providing better write throughput. Only the changes are replicated to other nodes, this is much quicker than processing the original transaction.
Implementing a Disaster Recovery Cluster
When using a cluster for disaster recovery, you must geographically distribute the nodes. This ensures that an outage event at one location will not effect the other.
Setting the weight of the DR node in GLB lower than the primary nodes would be appropriate.
Starting GLB with the
--single option sends all connections to a single server with the highest weight of those available.
Implementing a Cluster to Reduce Client Latency
By placing nodes "closer" network-wise to the clients, latency can be reduced. However, with greater latency between nodes, writes can be slower to complete. More common read-only access will be faster with lower latency. Note: GLB policy "source tracking" would be used here.
Recovering from a Crash
Any individual node crash can be recovered by restarting the node and allowing it to rejoin the cluster. However, if all nodes are stoppped, the most advanced node must be bootstrapped to recover the cluster.
Shutdown/Restart the Cluster
If you shut down all nodes at the same time, then you have effectively terminated the cluster. In order to restart, you'll need to bootstrap the cluster again.
Monitoring of your cluster is important to ensure it is running correctly. You can query individual nodes of the cluster, or configure the
wsrep_notify_cmd to track changes to the cluster.
Maximum Concurrent Connections
The maximum concurrent connections supported by Galera Load Balancer depend on the system's open files limit. The limit for unprivileged users is normally 4096, which results in a maximum of 2029 connections. The limit may be checked with
ulimit -n, and increased in
/etc/security/limits.conf if necessary.
In this course we discussed some theory of highly-available systems, and implimented a MariaDB Galera Cluster.
Take this course and learn a new skill today.
Transform your learning with our all access plan.Start 7-Day Free Trial