Galera Load Balancer (GLB) is a scalable and performant, yet easy to use TCP/IP connection balancing proxy. It draws from Pen Load Balancer, but it does a lot more. For the longest time, we have encouraged you to compile it from our GitHub repository, but now we are happy to tell you it is available as part of Galera Cluster Enterprise Edition, and we provide pre-compiled binaries of Galera Load Balancerthat have passed our extensive QA processes.
It started life in May 2008, effectively making it a proxy that is fourteen years old (and now, the oldest but actively maintained surviving MySQL-specific load balancer out there). For context, the now deprecated MySQL Proxy started life in 2007 and was EOLed in 2014, while MariaDB MaxScale started life in 2015, alongside MySQL Router and ProxySQL (2015 was a big year for MySQL proxies!). While you may find native Galera Cluster hostgroup support in ProxySQL, and you will also find Galera Monitors in MariaDB MaxScale, it is worth noting that Galera Load Balancer (GLB) has been around for a long time, and is finally being productized, clearly because we have seen customer demand for it and customers are using it in production.
So, why a load balancer, in the first place? After all, Galera Cluster is a true multi-master cluster where all nodes are equal and you don’t have a need for load balancing, correct? Well, sometimes, depending on some workloads, you may benefit from having a load balancer. For one, setting up a three-node cluster alone does not make your application highly available – it needs to know that it can connect to any of the three nodes, right? In some instances, your connector will support passing multiple IP addresses (e.g. Connector/J, the PHP mysqlnd driver, etc.). In other instances you’ll do it within the application. But in most cases, you’ll probably want the likes of Galera Load Balancer (GLB).
Galera Load Balancer (GLB) is multi-threaded, so it uses multiple CPU cores, of which modern machines have a lot of. It also has the ability to configure back-end servers at runtime (so you can add or remove nodes at any given time), and most interestingly it also has a watchdog module to monitor the destinations and update the routing table if required. It can in theory run from the command line and you can pass service options to reconfigure it, but we naturally always recommend you to have a configuration file (it is as simple as /etc/glbd.cfg). GLB supports destination selection policies like least connected (default, this ensures that all your nodes are being used effectively), round-robin, random and source tracking. Maybe one of the more interesting ones is single: you can effectively drive all traffic to one single Galera Cluster node, and just have the other two as High Availability failover options!
We are going to talk about Galera Load Balancer (GLB) over the next few blog posts (getting started with an installation, how to drain servers, how to reduce read latencies, etc.), but we hope that this alone has whet your appetite over thinking about trying to use Galera Load Balancer (GLB). We haven’t run recent benchmarks, but this might also be a focus for us. Remember, we have documentation, but you don’t have to compile it, manually install the service, copy configuration files, etc. – you can just get it via Galera Cluster Enterprise Edition or request the binaries by contacting us at sales@galeracluster.com.