Datenbank-Proxy MariaDB MaxScale

Bitte weitersagen

Relationale Datenbanken wie MariaDB oder MySQL sind das Rückgrat des Internets und unzähliger Anwendungen. Um mit den heutigen Anforderungen Schritt zu halten, reichen die Bordmittel der Database-Management-Systeme schon lange nicht mehr aus. Nach Clustering und Master/Slave-Replikation versucht MariaDB nun mit MaxScale, die zentralen Probleme der Datenbanken in Zeiten von Big Data zu lösen.
Open Source-Software findet in immer mehr Unternehmen und Behörden ihren Einsatz. Im Juli widmet IT-Administrator daher seinen Heftschwerpunkt der quelloffenen ... (mehr)

Wer Anwendungen entwickelt oder Websites betreibt, nutzt in der Regel eine Datenbank als zentrale Komponente. Nicht nur aus Kostengründen setzen viele Unternehmen und Entwickler dabei auf Open Source-Lösungen. MySQL und dessen Fork MariaDB gehören nicht umsonst mit zu den meistgenutzten Database-Management-Lösungen: Sie sind kostenlos, solange kein professioneller Support benötigt wird. Im kritischen Bereich können alle Services dazugebucht werden, die für einen sicheren und zuverlässigen Betrieb einer darauf aufbauenden Anwendung notwendig sind. Doch die Technologien der relationalen Datenbank und der Abfragesprache SQL haben Grenzen.

Ein grundsätzliches Problem, das heute durch die großen Datenmengen, die verarbeitet werden müssen, immer dringender wird, ist die Skalierbarkeit. Hier haben sich zwei Methoden etabliert, die für ein gutes Antwortverhalten und Ausfallsicherheit der Datenbankserver sorgen: Cluster mit Master/Slave-Replikation und Sharding. Doch beide Ansätze, die häufig kombiniert werden, machen die Administration der Datenbank-Infrastruktur sehr komplex. Oft wird auch die Anwendungsentwicklung dadurch erschwert, da die Entwickler die Master/Slave-Struktur teilweise in ihren Applikationen berücksichtigen müssen. Beim Sharding steigt zudem der Administrationsaufwand extrem an, wenn eine Tabelle geändert werden muss.

Durch Clustering und Sharding lassen sich also zwar eine hohe Verfügbarkeit und gute Antwortzeiten erzielen. Konterkariert wird das jedoch zunehmend durch die Notwendigkeit, Anwendungen rund um die Uhr verfügbar zu halten. Geplante Downtimes in einer komplexen Infrastruktur sind nur mit hohem Aufwand sicher durchzuführen. Updates und Upgrades müssen vorab ausführlich getestet werden, gegebenenfalls sind Anpassungen an der Anwendung oder dem Datenbanksystem notwendig. Hier kann eine Entkopplung der Daten- von der Anwendungsschicht Abhilfe schaffen und die Komplexität in den Hintergrund rücken.

Datenbankspezifischer Proxy

Der jüngst vorgestellte Proxy namens MariaDB MaxScale bildet eine Abstraktionsschicht zwischen der Anwendung und den Datenbanken. Das Konzept eines Datenbank-Proxy ist nicht ganz neu, auf dem Markt sind bereits einige Proxy-Lösungen verfügbar. Diese fokussieren jedoch häufig auf bestimmte Teilbereiche wie Replikation oder Lastverteilung. Hier geht MariaDB einen deutlichen Schritt weiter und stattet MaxScale mit zahlreichen Funktionen aus, die dem Administrator das Leben leichter machen sollen und auch über die Möglichkeiten des bereits etablierten MySQL-Proxy hinausreichen (Bild 1).

Bild 1: Der MaxScale-Proxy zwischen Anwendung und Datenbank deckt mehrere Facetten ab.

Das wichtigste Designmerkmal von MaxScale: Der Proxy-Server ist für die Anwendungen vollständig transparent. Für die Anwendungsschicht bildet MaxScale einfach eine ganz normale Datenbankinstanz ab. Das bedeutet, dass Änderungen an den Datenbanken generell keine Auswirkungen auf die Anwendungen haben; auch kann die Datenbank unabhängig von der Anwendung skalieren. Für die Anwendungsentwickler macht das die Arbeit erheblich einfacher. Aber auch für die Datenbank-Admins wird das Leben so leichter. Im Gegensatz zu anderen DB-Proxys verarbeitet MaxScale die Anfragen auf genau dieselbe Art und Weise, wie es Maria­DB oder MySQL machen, was deutliche Geschwindigkeitsvorteile verspricht.

Bild 2: Der Proxy kann SQL-Statements analysieren und abhängig vom Ergebnis mehrere Log-Dateien schreiben.

Zunächst fungiert MaxScale als Loadbalancer und kümmert sich um die gleichmäßige Verteilung der Abfragen und Verbindungen. Die Besonderheit dabei ist, dass MaxScale für Datenbanken optimiert ist. Im Gegensatz zum generischen Loadbalancing kann der Proxy den Datenverkehr parsen und damit auch kontextsensitiv auf Basis der SQL-Requests agieren. Der Proxy beherrscht dazu sowohl Connection- wie auch Statement-basiertes Load Balancing. Beim Connection-basierten Load Balancing überprüft der Proxy den Inhalt der Requests nicht, die an die Datenbank geschickt werden. Das Routing der Lesezugriffe bei der Master/Slave-Replikation basiert ausschließlich auf der aufgebauten Verbindung zwischen den Anwendungen und der Datenbank. Hierbei kommt Round Robin als Scheduling-Verfahren zum Einsatz.

Ähnlich arbeitet der Proxy im Zusammenspiel mit Galera-Clustern. MaxScale arbeitet nahtlos mit dem Cluster zusammen und kann das Load Balancing über mehrere Master im Cluster hinweg steuern. Dazu überwacht der Proxy jeden Knoten im Cluster und leitet die Anfragen nur an solche Nodes weiter, die vollständig synchronisiert sind. Damit kann die Verfügbarkeit eines Clusters noch weiter gesteigert werden: Mit diesem Connection-basierenden Verfahren lassen sich einzelne Knoten des Clusters sehr einfach und dynamisch aus dem Verbund entfernen oder hinzufügen, was bei geplanten Wartungsarbeiten wie Updates hilfreich ist.

Proxy nimmt die Arbeit ab

Da Anwendungen für das Zusammenspiel mit der Master/Slave-Replikation vor allem für Schreibzugriffe explizit ausgelegt sein müssen, bietet MaxScale interessanterweise gleich eine Lösung für Apps an, die keine getrennte Verbindung für Read- und Write-Abfragen verwenden. Beim Statement-basierten Load Balancing kommuniziert die Anwendung über eine einfache Verbindung mit dem Proxy. Dieser untersucht die Statements und entscheidet, ob die Anfragen an den Master oder an einen Slave weitergeleitet werden. Damit entfällt die Notwendigkeit, Anwendungen für die Skalierbarkeit bei Lesezugriffen „Replication aware“ zu entwickeln. Auch bei der Performane-Analyse ist das SQL-Verständnis des Proxy nützlich: So kann er etwa dabei helfen, für unterschiedliche Zwecke eigene Log-Dateien anzulegen (Bild 2).

Die Fähigkeit von MaxScale, Querys zu analysieren, bringt auch an anderer Stelle einige Vorteile. So ist es möglich, SQL-Requests vor der Auslieferung an die Datenbank zu prüfen und damit die Gefahr einer SQL-Injection zu senken. Zudem erlaubt es MaxScale, Legacy-Anwendungen für aktuellere Versionen von MariaDB oder MySQL nutzbar zu machen, ohne den Code der Applikation selbst ändern zu müssen. Änderungen in der Syntax werden dabei vom Proxy über einen Filter berücksichtigt und in den Queries und Antworten ersetzt. Aus dem Befehl

CREATE TABLE… TYPE = InnoDB

alter MySQL-Versionen wird so die aktuelle Variante:

CREATE TABLE… ENGINE = InnoDB

Damit lassen sich auch Datenbanken mit abweichenden SQL-Dialekten für bestehende Anwendungen nutzbar machen. Besonders hilfreich ist diese Möglichkeit, wenn Datenbanken migriert werden sollen. Durch die Filter können die DB-Server asynchron ohne Ausfallzeit auf eine neue Version umgestellt werden. Obendrein erlaubt es MaxScale, Anfragen für andere Datenbank-Systeme, Speicher-Engines oder Anwendungen zu duplizieren. Daten lassen sich auf diesem Weg auch an Tabellen mit unterschiedlichen Engines senden.

Die Basis für die Funktionsvielfalt ist die Plug-in-Architektur des Datenbank-Proxy. Hier greift MariaDB das bereits bei MySQL und MariaDB bewährte modulare Konzept auf. Bislang ist die Zahl der verfügbaren Module noch überschaubar. So etwa bei den Client-Protokollen: Zum Produktstart arbeitet MaxScale mit MariaDB Enterprise, MariaDB Enterprise Cluster, MariaDB 5.5, MariaDB 10 und Oracle MySQL zusammen. Das Loadbalancing setzt den Einsatz von MariaDB Galera Cluster, MariaDB Master/Slave Replication oder Oracle MySQL Server Replication voraus.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023