« Previous 1 2 3 4
MariaDB MaxScale: A smart proxy for MySQL
Director
Accelerating Cloud Setups
Performance tests in the run-up to this article showed that MaxScale is impressive, particularly in throughput. In terms of latency, the service cannot improve on physical limits; latency obviously cannot be smaller than the latency of Ethernet. However, MaxScale can offer real added value in cloud setups: Existing software-defined network (SDN) implementations are often responsible for latency that is significantly above that of Ethernet.
From version 1.3 on, MaxScale supports persistent database connections to its back ends. MaxScale then opens connections in the background and distributes incoming requests from clients to the already open connections. In this case, it avoids a major part of the network overhead that drives latency in SDN environments. If you need MySQL to be faster than ever before (e.g., on Amazon or Rackspace), MaxScale 1.3 takes you closer to this goal.
Hardening Against Failures
Although MaxScale ensures reliable MySQL, it can itself become a single point of failure. If your own setup is entirely based on MaxScale, a problem arises as soon as MaxScale fails. However, it is not particularly difficult to make MaxScale highly available. In one approach, several instances of MaxScale can access the same database back ends in parallel; then, you manually distribute the physical clients across the available instances of MaxScale so that a failure does not take down the whole setup. Another approach would be deploy a classic load balancer upstream of the MaxScale instances, although this is not ideal in terms of latency.
An alternative solution is the classic cluster manager: For a single instance of MaxScale, all you need is an active-passive setup (e.g., with Pacemaker). A team consisting of a flexible service IP and MaxScale easily moves from one host to another in this variant. In fact, MaxScale describes the setup in a company blog [8].
Conclusions
MaxScale by MariaDB turns out to be a very handy addition to MySQL clusters. It supports both Galera clusters and back ends that follow the master-slave principle, which is already installed as the factory default in MySQL.
MaxScale solves several problems at once for admins. On one hand, the MaxScale-MySQL-Galera team lets you create a database that scales horizontally, even if the client is not specifically equipped to talk with several database instances. Thanks to MaxScale, practically any MySQL client can use this kind of cluster, and MaxScale itself meets all the requirements of the database on the client side.
Administrators of master-slave clusters will particularly look forward to the ability to split reads and writes. Auxiliary features, such as monitoring database clusters or logging queries separately, contribute to the overall positive impression.
If you run MySQL and are thinking of scaling your setup horizontally in the near future, you should consider MaxScale as part of the deal.
Infos
- HAProxy: http://www.haproxy.org
- F5: https://f5.com
- MaxScale website: https://mariadb.com/products/mariadb-maxscale
- MaxScale on GitHub: https://github.com/mariadb-corporation/MaxScale
- MaxScale packages: https://mariadb.com/my_portal/download#maxscale
- router_options values for readconnroute: https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale/maxscale-readconnroute/
- MaxScale as the binlog server: https://github.com/mariadb-corporation/MaxScale/blob/master/Documentation/Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md
- MaxScale with Pacemaker: https://mariadb.com/blog/how-make-maxscale-high-available-corosyncpacemaker
« Previous 1 2 3 4
Buy this article as PDF
(incl. VAT)