Seite wählen

NETWAYS Blog

HAProxy und SQL Grants

In diesem kurzen Beitrag will ich auf einen Fallstrick im Bezug von HAProxy und SQL Backends wie MySQL oder MariaDB eingehen. Speziell geht es um Grants und die damit verbunden Quell Hosts. Diese werden bei einem Standard Setup mit HAProxy durch die IP des Proxys ersetzt. Solange man sich in dem selben Netz wie die DB Server und dem Proxy befindet und die Host-Beschränkungen nicht all zu streng sind, kann es gut sein, das man dieses Szenario nicht erreicht. Sobald die Verbindungen aber Netz übergreifend erfolgen und die Grants damit umso wichtiger sind, kommt das Detail zum Tragen und stellt einen vor neue Herausforderungen. Dafür gibt es an sich schon etwas länger das Proxy Protokoll, welches aber erst nach und nach in mögliche Backend Software implementiert wurde/wird. Bei MariaDB war es mit der 10.3.1 z.B. erst Ende letzten Jahres soweit.
Die Arbeitsweise des Protokolls beschreibt sich einfach gesagt so, dass mit dem Aufbau der Verbindung zuerst ein zus. Header geschickt wird, in dem die IP des Quell Hosts bekannt gegeben wird. Dazu muss das Backend jedoch von der IP des HAProxys das Proxy Protokoll erlauben. Das Ganze drum rum kann mit Seiten über weitere Details und Sicherheit befüllt werden. Damit verschone ich Euch aber und weise nur auf eine schlichte Zusammenfassung im Blog von HAProxy hin.

Analyse der Konfigration bei Galera-MySQL-Cluster

Ich möchte in diesem Blog-Beitrag noch Ergänzungen zum Galera-Blog von Marius zum Thema Konfiguration-Check machen.
Zum Beispiel kann man bestimmte Statis abfragen, ob der Cluster synchronisiert ist oder wie viele Nodes der Cluster besitzt und noch einiges mehr.
Kurz zum Verständnis bei MySQL ist das Prozentzeichen(%) das Wildcard wie bei der Bash das Sternchen(*).
Das werde ich Anhand nachfolgender Beispiele erklären.
Die Anzahl der Nodes im Cluster:
mariaDB [(none)]> show status like 'wsrep_cluster_size%';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 3 |
+--------------------+-------+

Wie man sehen kann sind hier 3 Nodes im Cluster.
Den aktuellen Sync-Status im Cluster wird so ermittelt:
MariaDB [(none)]> show status like 'wsrep_local_state_comment%';
+---------------------------+--------+
| Variable_name | Value |
+---------------------------+--------+
| wsrep_local_state_comment | Synced |
+---------------------------+--------+

Die Ausgabe sollte hier selbsterklärend sein.
Um alle Statis von dem Cluster abzurufen kann man dieses Kommando benutzen:
show status like 'wsrep_%';
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 25.3.19(r3667) |
| wsrep_ready | ON |
| wsrep_received | 56804 |
| wsrep_received_bytes | 2506329647 |
| wsrep_repl_data_bytes | 352492270

Das ist nur ein kleiner Ausschnitt aus dem Ouput der hier herauskommt
Jetzt kommen wir zur eingestellten Konfiguration, die man hier auch auslesen kann, um spätere Anpassungen vorzunehmen kann.
Die Werte dafür sind in Variablen bei MySQL gespeichert und können wie folgt abgerufen werden:
Die max_allow Variablen kann man so ermitteln:
MariaDB [(none)]> show variables like '%max_allow%';
+--------------------------+------------+
| Variable_name | Value |
+--------------------------+------------+
| max_allowed_packet | 536870912 |
| slave_max_allowed_packet | 1073741824 |
+--------------------------+------------+

Wenn man hier etwas herumspielt mit den Werten, kann man erstaunliches und informatives herausfinden.
So als kleiner Einstieg sollte dieser Beitrag ausreichen damit man die wichtigsten Einstellungen beim Galera-Cluster ausgegeben bekommt.
Lesenswert Link:
Galera Dokumtentation
Empfehlenswert sind natürlich unsere Schulungen im Bereich, die auf jeden Fall einen Blick wert sind.

Johannes Carraro
Johannes Carraro
Senior Systems Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

Monthly Snap April > NETWAYS Web Services, Braintower, OSBConf, Teamweekend, AKCP, OSDC, GitLab CE, Galera, GitHub, Puppet

In April, Isabel startet with announcing a new Software Update for Braintower and Martin K. continued with a new NETWAYS Web Services tool: Rocket.Chat Hosting.
Then Julia announced the call for papers for the Open Source Backup Conference 2017 in Cologne while Marius wrote about the end of Ubuntu 12.04 LTS.
Later in April, Marius H. gave some practical tips for the Galera Cluster and Dirk wrote about contributing to projects on GitHub.
Then Martin K. presented the next NETWAYS Web Services App, GitLab CE Hosting, and Julia told about the latest OSDC-News.
Furthermore, Catharina reviewed the team event of the commercial departments while Noah told us how to block some Google searches in Google Chrome.
Lennart gave an insight in the monitoring project at htp GmbH and Daniel introduced himself.
Towards the end of April, Isabel told about the latest news concerning the AKCP sensorProbe 2+ and Martin S. explained external monitoring by the Icinga2 satellites at NETWAYS Web Services.
Last but not least, Jean reported on monitoring powershell scripts with Icinga 2, while Lennart went on with part 2 of automated monitoring with Puppet.

Galera Cluster – Tips für die Praxis

Galera Cluster für MySQL ist mal ein „einfacher“ Cluster für MySQL und seit MariaDB Version 10.1 standardmäßig mit an Board. Dadurch erhält man mit ein paar Zeilen Konfiguration einen produktionsfähigen Cluster, um den man sich wenig kümmern muss. In der Praxis allerdings, bieten sich genügend Fallstricke, die es zu meistern gilt.

Die Terminologie

  • Joiner: Neues Member welches dem Cluster hinzugefügt wird
  • Donor: Meldet sich ein Joiner stellt der Cluster einen Lieferanten bereit welcher die Daten auf den Joiner überträgt
  • SST: Snapshot State Transfer – Ist Lücke zum aktuellen Stand zu groß, werden der komplette Stand übertragen
  • IST: Incremental State Transfer – Im laufenden Betrieb werden Änderungen direkt übertragen. Die Änderung ist am Cluster erst verfügbar wenn alle Mitglieder diesen Stand empfangen haben

Tipps

1. SST Vermeiden

Einen kompletten Stand der Daten zu übertragen ist keine gute Idee. Ein Cluster, welcher 1 TB Nutzdaten verwaltet, ist auch nach drei Tagen nicht fertig. Dadurch können stabile Member ihre Integrität verlieren und der Cluster wird instabil. Hat man eine solche Situation erreicht empfiehlt es sich, den kompletten Cluster manuell zu syncen (MySQL Daten löschen und per rsync kopieren – Aber bitte keine Binlogs!).

2. SST Method

Galera bietet verschiedene Methoden um einen SST durchzuführen. Laut Statistik ist SSH die schnellste Methode – D’Accord – Aber der dadurch entstehende Donor ist für Anfragen gelockt und fällt aus dem Cluster. Dadurch wären wir bei Punkt 1 angelangt. Der beste trade-off ist hier xtrabackup-v2. Dadurch wird ein Donor am wenigsten blockiert. Bitte dabei den Benutzer zur MySQL Authentifizierung nicht vergessen – Sonst geht gar nichts!

3. SST Konfiguration

SST und das ausführen auf dem Joiner kann maßgeblich verbessert werden mit folgender MySQL Konfiguration:

[sst]
inno-apply-opts="--use-memory=20G"
compressor="pigz"
decompressor="pigz -d"

Dadurch geben wir dem innobackupex Script, welches auf dem Joiner ausgeführt mehr Speicher um Daten aus den Logs (–apply-log) auszuführen. Weiterhin parallelisieren wir den Vorgang um Daten auf dem Donor zu komprimieren und – guess what – auf dem Joiner zu dekomprimieren.
Um die Transaktionen weiter zu parallelisieren erhöhen wir die Einstellung wsrep_slave_threads auf eine dem System angepasste Anzahl (Anzahl Cores und Auslastung).

4. Dedizierten Donor

Bei großen Datenmengen empfiehlt es sich einen eigenständigen Donor bereitzustellen welcher keine Anfragen entgegen nimmt.

[mysqld]
 wsrep_sst_donor = node-donor

Eventuell sollte man auch Queries mit der Einstellung wsrep_sst_donor_rejects_queries verbieten

5. Locking Queries

Galera ist maximal transparent für Applikationen. Einzig, LOCKING wird nicht akzeptiert. Falls es von der Applikation benötigt wird könnte man mit der Einstellung wsrep_convert_LOCK_to_trx die Queries in Transaktionen kapseln.

6. Provider Cache

Standardmäßig auf 128M eingestellt, enthält dieser Ringpuffer die zu Verfügung stehen write-sets für einen IST. Die Größe sollte man entsprechend hoch wählen. So kann auch bei größeren Lücken immer noch ein IST durchgeführt werden:

[mysqld]
wsrep_provider_options="gcache.size=1G"

Bei entsprechend Arbeitsspeicher oder SSD Storage ist es durchaus eine gute Idee die Datei auf das schnellste Storage zu legen oder eine Lastaufteilung vorzunehmen:

[mysqld]
wsrep_provider_options="gcache.size = 8G; gcache.name = /var/cache/ssd/galera.cache"
7. HAProxy verwenden

Der stabilste Cluster bringt einem gar nichts wenn man nur einen Knoten abfragt. Eine der Stärken von Galera ist es, von allen Knoten zu lesen. Hier sollte man sich Gedanken zur Aufteilung machen:

  • Die schnellsten Knoten zum lesen und in den HAProxy
  • Donor exkludieren
  • Backup members bereitstellen (hot-standby)

Eine Konfiguration können z.B. folgendermaßen aussehen:

backend mysql_pool   mode tcp
  balance roundrobin   option mysql-check user haproxy   option tcpka # keep-alive!   server galera-donor1   192.168.17.20:3306 check inter 12000 disabled   server galera-standby1 192.168.17.21:3306 check inter 12000 disabled   server galera-node3    192.168.17.22:3306 check inter 12000
  server galera-node4    192.168.17.23:3306 check inter 12000
  server galera-node5    192.168.17.24:3306 check inter 12000

Dadurch erhalten wir einen Donor, einen hot-standby und drei read-heads. Durch die HAProxy API kann man das auch je nach Zustand des Cluster zu oder abschalten. Auch wäre eine standortübergreifende Verteilung möglich. Man stelle sich verschiedene Pools in verschiedenen Ländern vor. Je nach Ursprung und Applikation können dann die Anfragen zu den schnellsten read-heads weitergeleitet werden. Dann sollte man sich aber überlegen, z.B.  wsrep_dirty_reads an den Standorten zu verwenden.

8. Bin Logs

Ein richtiger Klassiker der Cluster Pitfalls, die Binary Logs von MySQL. Man würde sie für Galera nicht unbedingt benötigen aber sie bieten Sicherheit beim Crash und helfen einen SST im Falle zu vermeiden. In großen Umgebungen muss man folgendes bedenken:

  • Speicherplatz begrenzen
  • Vorhaltezeit verkürzen
  • An das verfügbare Storage anpassen

Ansonsten dauert ein FLUSH LOGS gerne auch mal 3 Tage und blockiert einen unseren Knoten – Beim Donor besonders schlecht!

Fazit

Für mich ein fantastisches Cluster System für MySQL! Es gibt noch viele gute Tips da draussen und noch viel mehr Möglichkeiten (und auch schmerzen) mit InnoDB / MySQL Konfiguration. Es funktioniert auch leider beim Galera Cluster nichts ohne vorher die eigene Rübe einzuschalten 😉

Links

 

Marius Hein
Marius Hein
Head of IT Service Management

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert und viele Jahre in der Softwareentwicklung gearbeitet. Mittlerweile ist er Herr über die interne IT und als Leiter von ITSM zuständig für die technische Schnittmenge der Abteilungen der NETWAYS Gruppe. Wenn er nicht gerade IPv6 IPSec Tunnel bohrt, sitzt er daheim am Schlagzeug und treibt seine Nachbarn in den Wahnsinn.

Galera Clustering

Viele von Euch kennen es bestimmt schon, das Project Galera. Dieses vereint die wsrep API mit MySQL bzw. dessen Fork MariaDB. Zum aktuellen Zeitpunkt werden schon InnoDB und die XtraDB – Storage Engine unterstützt. Letzteres ist eine InnoDB-Erweiterung und wird von Percona entwickelt .

Galera-Cluster-logo-1024x195

Der Galera Cluster bringt folgende Features/Benefits mit:

  • Multi-Master schon von Haus aus
  • Synchrone Replication kein Datenverlust mehr auch keine Slave-Lags mehr (Boa wie mich das immer wieder nervt)
  • Eng gekoppelt Alle Knoten haben grundsätzlich denselben Status, keine Daten mehr die auseinander laufen
  • Multi-threaded Slave für bessere Performance der Nutzlast
  • Keine Master-Slave Failover Operationen nötig oder die Notwendigkeit eine virtuelle IP binden zu müssen
  • Hot Standby keine Downtimes während des Failover (denn es gibt keinen Failover mehr)
  • Automatic Node Provisioning kein manuelles Eingreifen mehr um Knoten in den Cluster zu bringen, die Daten werden automatisch auf den neuen Knoten repliziert
  • Supports InnoDB bald auch MyISAM (ist noch experimentell)
  • Transparent zur Application benötigt in Kombination mit GLB (oder HAproxy) keine Änderungen an der Applikation
  • Kein Aufspalten von Read und Write Operationen nötig (einfach Feuer auf das Ding 😉 ).

Galera ist somit die Lösung für Unternehmungen die ein hohes Aufkommen an Schreib- und Lese -Operationen in ihren Datenbanken erwarten. Die Main „Use Cases“ für den Betrieb des Galera Cluster sind eben kurz und gut, Skalierung der Schreib-Operationen, entkoppeln von Latenz Killern (wie zB. lange laufende Queries).
Die Entwickler des Forks MariaDB haben diese vielfältigen Möglichkeiten erkannt und bieten auf ihren Seiten Anleitungen zum Betrieb so eines Basic Setups an. Ebenfalls werden dort fertige Pakete für die Installation auf alle Major Linux Distributionen angeboten, somit fällt auch schon mal das Kompilieren weg.
Für das Setup können zwei Loadbalancing-Produkte zum Einsatz kommen: Zum einen der schon etwas in die Jahre gekommene (aber immer noch sehr beliebte) HAproxy und zum anderen GLB (Galera LoadBalancer), der eigens für Galera, aber außerhalb des Projekts entstanden ist. Wir bevorzugen für unsere Setups meist den GLB da dieser auch während der Laufzeit (wenn nötig auch automatisiert durch Skripte) konfiguriert bzw. gesteuert werden kann. Änderungen können somit im laufenden Betrieb und auch unter Last problemlos vorgenommen werden. Wenn es dann doch mal knapp wird, kann man im Betrieb ganz einfach einen weiteren Knoten hinzufügen 🙂