Geplant ist, künftig auch weitere Datenbank-Systeme zu unterstützen. Auch andere Basisfunktionen wie Authentifizierung oder Monitoring sind als Module realisiert. In der Regel sind die Module externe Shared Objects, die zur Laufzeit geladen werden können. Da die APIs naturgemäß bei einer Open Source-Lösung bekannt sind, kann MaxScale mit vertretbarem Aufwand auf den eigenen Bedarf und auf neue Einsatzszenarien angepasst werden. Es sollte also nicht allzu lange dauern, bis sich eine aktive Community rund um den Proxy gebildet hat.
Auch der Hersteller selbst hat in seiner Feature-Roadmap einige Funktionen aufgelistet, die für den Einsatz vor allem in komplexeren Umgebungen wichtig sind. So ist etwa geplant, ein für Galera spezifisches Modul zum Statement-basierenden Routing zu implementieren, mit dem das Deadlock-Risiko bei fehlgeschlagenen Transaktionen verringert werden soll. Zudem ist ein hierarchisches Routing-Modell geplant, mit dem sich verschiedene Routing-Methoden in einer festen Abfolge als Pipeline kombinieren lassen.
MaxScale kann sowohl in virtuellen Umgebungen als auch auf physischer Hardware betrieben werden. Aktuell unterstützt der Datenbank-Proxy folgende Linux-Derivate in der 64 Bit-Variante als Plattform: CentOS 5, 6 und 7, Red Hat Enterprise Linux 5 und 6, Fedora 19 und 20, Debian 6 und 7, Ubuntu 12.04 LTS, 13.10 und 14.04.
Eine Version für OpenSuse 13.1 soll demnächst verfügbar sein. Da MaxScale als Datenbank-Proxy mit einem sehr großen Datendurchsatz zurechtkommen muss, greift es intensiv auf die asynchronen I/O-Fähigkeiten des Epoll-Systems von Linux zu. Es empfiehlt sich also, MaxScale als dedizierten Server zu betreiben und keine weiteren Workloads auf diese Maschine zu nehmen. Aktuell ist MaxScale unter der GPLv2-Lizenz verfügbar. Binärdateien stehen unter [1] zum Download bereit, der Quellcode kann über Github [2] heruntergeladen werden.
Der MaxScale-Proxy von MariaDB lässt sich transparent zwischen eine Anwendung und die Datenbank schalten. Dabei bietet MaxScale zahlreiche Funktionen, die dem Administrator das Leben erleichtern sollen. Neben Loadbalancing und Hochverfügbarkeit bietet MaxScale noch viele weitere Möglichkeiten, um zum Beispiel SQL-Statements on-the-fly umzuschreiben. Hierbei ist MaxScale gegenüber anwendungsneutralen Loadbalancern auf TCP-Ebene im Vorteil.
(of)
Horizontale und vertikale Skalierung
Datenbanken müssen skalierbar sein, um auch bei wachsendem Datenvolumen und steigenden Zugriffszahlen leistungsfähig zu bleiben. Dafür stehen grundsätzlich zwei Ansätze zur Verfügung: horizontal und vertikal. Beim vertikalen Skalieren wird – vereinfacht gesagt – die Rechenleistung des Datenbankservers erhöht. Mehr CPUs und mehr Speicher erlauben größere Datenmengen und mehr Rechenoperationen. Dieses Verfahren hat vor allem wirtschaftliche Grenzen, da die Serverkosten mit zunehmender Performance extrem steigen. Beim horizontalen Skalieren wird deswegen die Last der Datenbankoperationen auf mehrere Server verteilt, was aus Kostensicht deutlich günstiger ist. Die einzelnen Server werden zu Clustern zusammengefasst. Jeder Cluster verfügt über einen Master und eine gewisse Anzahl von Slaves. Abfragen werden über Loadbalancing gleichmäßig auf alle Instanzen verteilt. Sharding ist eine Form der horizontalen Skalierung.
Link-Codes
[1] MaxScale-Download: https://mariadb.com/user/login?destination=my_portal/download#maxscale/
[2] MaxScale-Quellcode: https://github.com/mariadb-corporation/MaxScale/
Ein Datenbank-Proxy mit Open-Source-Lizenz hilft bei der Skalierung von Datenbanken und schafft Ausfallsicherheit.