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

Autor: Marius Hein

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

if exists for Column and Index Migrations in MySQL

Unfortunately MySQL does not provide an SQL statement for conditionally creating a column if it does not already exist. There also does not appear to be an easy way for dropping a column without causing an error if the column doesn’t exist. The same problem also applies to indices. This functionality however is commonly used for idempotent schema updates. Without stored procedures which take care of the changes you are lost. I would like to share a Gist on GitHub which helps for the following schema migrations:

  • Drop index if exists
  • Create index if not exists
  • Create unique index if not exists
  • Drop column if exists
  • Add column if not exists

I am using the INFORMATION_SCHEMA tables for testing for the existence of columns and indices. No special grant is necessary to query from those tables. The stored procedures have the following signature:

Drop index if exists
m_drop_index(table_name, index_name)

Create index if not exists
m_create_index(table_name, index_name, index_columns)

Create unique index if not exists
m_create_unique_index(table_name, index_name, index_columns)

Drop column if exists
m_drop_column(table_name, column_name)

Add column if not exists
m_add_column(table_name, column_name, column_definition)

After importing, you can use them instead of MySQL’s ALTER statements. Here is an example for adding the name column to the table person:

mysql> CALL m_add_column('person', 'name', 'varchar(255)');
Eric Lippmann

Autor: Eric Lippmann

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Ein Buch über Icinga 2

Erscheint am 27. Juni 2016

 
41suqaLOyCL._SX336_BO1,204,203,200_April 2015, nach Monaten des Schwankens machten sich dann zwei verbliebene Möchtegernautoren doch auf ein Buch zum Thema Icinga 2 zu verfassen. Wir wollten ein sehr praxisnahes Werk mit vielen Beispielen wie und mit welchen Plugins etwas zu überwachen ist. Herausgekommen sind 344 Seiten von denen sich 100 mit Plugins und deren Verwendung in Icinga 2 befassen. Vorweg erfolgt eine generelle Einführung, die Vorstellung des neuen Webinterfaces Icingaweb 2 als auch eine ausführliche Erläuterung wie man lokale Werte wie Load bzw. CPU bei Windows oder Disk Usage mit NRPE/NSClient++, SSH und selbstverständlich mit dem neuen Icinga Agenten ermittelt.

Dem Kapitel über Plugins ist noch die Vorstellung einer fiktiven Firma vorangestellt. Diese betreibt ein zweigeteiltes Netzwerk mit einem internen Netz und eine durch Perimeter abgetrennte DMZ. Anhand dieses Beispiels wird eine verteilte Überwachung implementiert. Im internen Netz ist ein Icinga-Server (Master) für die Überwachung der dortig angesiedelten Server und Dienste zuständig. Für die DMZ wird ein weiterer Icinga-Server (Satellit) verwendet, der die ermittelten Ergebnisse an den Master meldet.

Diese Icinga-2-Infrastruktur wird dann im Folgenden benutzt, um eine Vielzahl von Diensten zu überwachen:

  • Host Erreichbarkeit
  • Zeitserver und lokale Zeit
  • Webservices incl. Apache und Ngnix
  • Domain Name Services
  • DHCP
  • Kerberos
  • Mailempfang und -versand
  • Proxy-Server
  • Generische Portüberwachung am Beispiel von Jabber
  • Javabasierte Application-Server
  • SAP
  • Kibana
  • Microsoft-Infrastrukturdienste: CIFS, Terminalservice, Domaincontroller, Exchange
  • Datenbanken: MySQL, PostgreSQL, MS SQL, Oracle
  • LDAP
  • Redis
  • Elasticsearch
  • VMware vSphere
  • Hardware: IPMI, HP, Oracle Solais, Thomas Krenn, Netzwerk, Festplatten
  • NetApp
  • Qnap

Das letzte Drittel ist Graphing mit PNP4Nagios und Graphite, Logmangement, Reporting und Businessprozessen gewidmet.

Teilbereiche werden von den beiden Autoren in einem Workshop vor der diesjährigen Open Source Monitoring Conference mit den Teilnehmern zusammen praktisch umgesetzt.

Lennart Betz

Autor: Lennart Betz

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Nachgestellte Leerzeichen und String-Vergleiche in Datenbanken

Für Datenbanken die sich an den SQL-92-Standard halten, gilt für Vergleiche von character strings nach Abschnitt 8.2 Generals Rules #3, dass die zu vergleichenden Strings, vor dem Vergleich auf die selbe Länge gebracht werden müssen. Der eventuell kürzere String wird demnach nach rechts auf die Länge des zu vergleichenden Strings mit Hilfe eines pad character, meist dem Leerzeichen, aufgefüllt.

Unter character strings fallen die Typen char (character) und varchar (character varying). Diese Typen ähneln einander, werden aber auf unterschiedliche Weise gespeichert und abgerufen.
char-Werte werden beim Speichern nach rechts mit Leerzeichen bis auf die deklarierte Länge aufgefüllt, welche beim Abrufen aber wieder entfernt werden. Bei char-Werten mit einer maximalen Anzahl von vier Zeichen beispielweise, kann man deshalb nicht zwischen 'abc' und 'abc ' unterscheiden.
Im Gegensatz dazu werden varchar-Werte nur mit so vielen Zeichen wie erforderlich zuzüglich der Information über die Länge gespeichert. varchar-Werte werden beim Speichern nicht aufgefüllt. Somit werden auch Leerzeichen beim Speichern und Abrufen beibehalten.

Und jetzt? Jetzt wollen wir versuchen aus den varchar-Werten 'abc' und 'abc ' nur 'abc ' zu selektieren.

Als Erstes brauchen wir natürlich eine Datenbank mit den gewünschten Daten (hier in MySQL):

CREATE DATABASE playground;
USE playground;
CREATE TABLE pad (string varchar(5));
INSERT INTO pad VALUES('abc');
INSERT INTO pad VALUES('abc ');
INSERT INTO pad VALUES('abc  ');

Als Nächstes überprüfen wir, ob – wie im Standard definiert – bei varchar-Werten Leerzeichen beim Speichern und Abrufen beibehalten werden:

SET sql_mode = PIPES_AS_CONCAT;
 
SELECT '"' || string || '"', LENGTH(string) FROM pad;
 
+----------------------+----------------+
| '"' || string || '"' | LENGTH(string) |
+----------------------+----------------+
| "abc"                |              3 |
| "abc "               |              4 |
| "abc  "              |              5 |
+----------------------+----------------+

Das sieht doch gut aus. Nun zurück zur eigentlichen Aufgabe: Wir wollen aus diesen Daten nur 'abc ' selektieren:

SELECT '"' || string || '"', LENGTH(string) FROM pad WHERE string = 'abc ';
 
+----------------------+----------------+
| '"' || string || '"' | LENGTH(string) |
+----------------------+----------------+
| "abc"                |              3 |
| "abc "               |              4 |
| "abc  "              |              5 |
+----------------------+----------------+

Irgendwie nicht richtig. Oder doch? Wie eingangs erwähnt, tritt hier die Regel für Vergleiche von character strings aus dem SQL-92-Standard in Kraft: Der kürzere zu vergleichende String wird nach rechts mit Leerzeichen aufgefüllt. Wenn 'abc' mit 'abc ' verglichen wird, wird eigentlich 'abc ' mit 'abc ' verglichen, oder 'abc' mit 'abc' – wer weiß das schon so genau :).

Kommt man trotzdem auf das gewünschte Ergebnis? Klar, mit einem Zaubertrick:

SELECT '"' || string || '"', LENGTH(string) FROM pad WHERE BINARY string = 'abc ';
 
+----------------------+----------------+
| '"' || string || '"' | LENGTH(string) |
+----------------------+----------------+
| "abc "               |              4 |
+----------------------+----------------+

Gibt’s Ausnahmen? Ja! Bei PostgreSQL sind bei Vergleichen von varchar-Werten nachgestellte Leerzeichen signifikant.

Eric Lippmann

Autor: Eric Lippmann

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Cubietruck ( Entertainment in 1080p )

Was macht der Netways-Mitarbeiter, wenn er abends nach Hause kommt?

Er schaltet sein Entertainment-System ein und legt klassische Musik auf …

… Klassik? Nein nicht wirklich, das mit dem Entertainment System ist allerdings wahr.

Ich möchte euch hier etwas über mein Entertainment-System berichten, dem Cubietruck, einem leistungsfähigen Ersatz für den RaspberryPi.

cubietruck-hand

Zudem haben Netways-Mitarbeiter unter anderem noch andere Anforderungen an solch ein Spielzeug. 🙂 Hier mal einige mögliche Anwendungsthemen:

  • als MPI Cluster ( ja so Verrückte gibt es auch hier bei Netways 😉 )
  • als WLAN AP ( oder Bluetooth FileShare )
  • als Network Monitoring TAP ( für die Traffic Analyse im heimischen Netzwerk – aber auch in Firmennetzen ganz hilfreich )
  • als NAS ( mit Samba und NFS als Shared-Storage für Backup von Fotos, Dokumenten etc. … )
  • als Mobile Computer ( zum Surfen, Schreiben, Programmieren sogar mit dem heimischen Fernseher )
  • als Computer zum Lernen ( für die Kleinen aber auch ganz Großen )
  • als Home Entertainment-System ( mit KODI ehemals XBMC, wahrscheinlich das, was sich viele als Ersatz oder gar Ergänzung zu einer Set-Top Box wünschen )

Mit der Installation von Ajenti oder einer der anderen WebGUI’s ( OpenPanel, Webmin ) ist es möglich das Gerät vollständig über ein Webinterface zu steuern, in Kombination mit OwnCloud und MySQL/MariaDB ist das System eine vollwertige CloudSharing Lösung.

Auch LXDE oder gar XFCE stressen die Allwinner A20 CPU nicht sonderlich. Somit ist das System auch als Lerncomputer für die Kids ganz gut geeignet (es muss nicht immer teure Hardware sein) .

Die Bastler unter euch haben bestimmt auch ganz exotische Vorstellungen bzgl. Networking. So ist es möglich, den Cubietruck auch als WLAN AP einzusetzten. Entweder händisch mit OpenWRT oder auch ganz bequem über die WebGUI mit DD-WRT. Die ganz Pfiffigen unter euch basteln sich das Ganze auf Basis der verfügbaren Distributionen in wenigen Minuten selber zusammen.

cubietruck-case

Viele von euch haben dieses System vermutlich bereits für sich erkannt, und Fragen sich bestimmt „Warum berichtet er uns hier den über ein Gerät das bereits ca. ein halbes Jahr alt ist?“, und die Antwort ist „Kinderkrankheiten“, jedes System bzw. OS ist in der Phase seiner Entwicklung noch recht verbugged, das betraf auch das Cubieboard3. Der Cubietruck ist momentan der beste Ersatz für den RaspberryPi, wenn es um Leistung und Ausstattung geht.

Hier mal die Hardware Ausstattung des Cubieboard3 ( aka Cubietruck ):

  • AllWinnerTech SOC A20 ARM® Cortex™-A7 Dual-Core ARM®
  • 2GB RAM DDR3
  • VGA & DVI 1080P
  • 10/100/1000Mbit Ethernet
  • Wifi+BT ( in einem Chip )
  • SATA 2.0 Port für 1.8/2.5′ HDDs ( auch 3.5′ HDDs sind möglich brauchen allerdings einen externen Strom Anschluss )
  • MicroSDHC Slot sowie NAND 4GB ( mit vorinstalliertem Android )
  • 2 x USB 2.0
  • 1 x Infrarot
  • 1 x 3.5 klinke
  • 1 x LED ( diese könnt Ihr auch selber ansteuern )
  • 1 x SPDIF
  • 1 x Power DC5V@2.5A ( ein altes Smartphone USB-Ladegrät reicht hier aus )
  • 1 x 54 Pin
  • 1 x JTAG & UART over USB
  • Board Abmessung 11 x 8 cm
  • mitgeliefert werden Plexiglass und Schrauben ( als Provisorisches Gehäuse ganz nett anzusehen )

cubietruck-overview

Die folgenden Links könnten für den Einstieg ganz Hilfreich sein.

Sonstiges:

 

Enrico Labedzki

Autor: Enrico Labedzki

Enrico ist beruflich ganz schön rumgekommen – IT hat ihn aber immer beschäftigt. Nach einem Ausflug in die Selbstständigkeit im Bereich Webentwicklung und Network Solutions, wurde es dann Zeit Nägel mit Köpfen zu machen und endlich den Weg als Softwareentwickler und Systemintegrator einzuschlagen. In seiner Freizeit widmet sich der passionierte Bastler der Elektrotechnik und Animatronik. Bei Netways bereichert er mit seinem vielseitigen Know-How das Managed Service-Team.

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 🙂

Enrico Labedzki

Autor: Enrico Labedzki

Enrico ist beruflich ganz schön rumgekommen – IT hat ihn aber immer beschäftigt. Nach einem Ausflug in die Selbstständigkeit im Bereich Webentwicklung und Network Solutions, wurde es dann Zeit Nägel mit Köpfen zu machen und endlich den Weg als Softwareentwickler und Systemintegrator einzuschlagen. In seiner Freizeit widmet sich der passionierte Bastler der Elektrotechnik und Animatronik. Bei Netways bereichert er mit seinem vielseitigen Know-How das Managed Service-Team.