Seite wählen

NETWAYS Blog

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.

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
Eric Lippmann
CTO

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 für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Vorträge der OSBConf 2016

Nachdem Daniela vor Kurzem ja schon was zu den vorgelagerten Workshops und zum Rahmenprogramm der diesjährigen Open Source Backup Conference in Köln geschrieben hat (siehe: Rauchende Köpfe, knurrende Mägen…), möchte ich noch etwas über die Vorträge dort berichten.
img_0802Nach einer kurzen Begrüßung durch Maik Außendorf von der dass IT ging’s los mit Julius Faubel von der Tandberg Data GmbH. Er referierte über Backup to Tape und stellte anschließend die Produkte der NEOxl, NEOs und der NEOe-Series vor. Gregor Wolf von Red Hat sprach anschließend über die Herausforderungen der Datenexplosion und wie man diese in den Griff bekommen kann.
Die Neuerungen von Bareos 16.2 und deren Roadmap für nächstes Jahr wurde uns von Philipp Storz und Maik Außendorf präsentiert. Neben anderen neuen Features wurde besonders anschaulich auf „Always Incremental“ eingegangen, welches besonders bei großen Datenmengen Zeit- und Netzwerkkapazität reduziert.
Vor der ersten Kaffeepause zeigte Erol Ülükmen noch welche besonderen Ansprüche das Clientmanagement mit sich bringt und wie sich das Open Source Clientmanagementsystem Opsi (Open PC Server Integration) mit Bareos integrieren läßt.
Gratien d’haese, der am Tag zuvor auch schon den Workshop zu REAR (Relax-and-Recover) gehalten hatte, erklärte was bei einem Business Continuity Plan zu beachten ist und wie man das darin enthaltene Disaster Recovery mit Bareos und REAR abbilden kann. Einen praktischen und interessanten Einblick wie das Backup bei der Friedrich-Schiller-Universität in Jena mit Bareos durchgeführt wird, gab’s vor der Mittagspause noch von Thomas Otto.
img_0805Gut gestärkt hörte man Jörg Brühe zu, der über Datenbank Backup referierte. Dabei wies er v.a. auf Dringlichkeit und Testmöglichkeiten von Restores hin.
Später stellte Christian Reiß von Symgenius ZFS vor und zeigte wie es mit Bareos zusammenspielt. Das Deployment dafür wurde mit Puppet gelöst, weshalb er auch auf das von ihm geschriebene Bareos-Puppet Modul näher einging.
Tobias Groß präsentierte nach der Kaffeepause am Nachmittag wie sinnvoll ein skalierendes Backup anhand von Bareos Active Clients und Puppet ist, allerdings wurde das dafür benutzte Puppetmodul globalways-bareos leider aktuell noch nicht publiziert. Eine belebte Diskussionsrunde über diverse Themen bildete dann den gelungenen Abschluss der Konferenz, bevor alle Teilnehmer mit einem Lunchpaket im Gepäck den Nachhauseweg antraten.
Die Open Source Backup Conference findet im nächsten Jahr vom 25. bis zum 26. September mit hoffentlich ebenso interessanten Vorträgen sowie einem breiten Publikum wieder in Köln statt, also bis dann!

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Icinga2 & LSW

Ich musste feststellen das man mit dem Linux Subsystem for Windows auch Icinga2 + Icingaweb2 auch zum laufen bringen kann auf einem Windows.
Also hier mein kleiner Erfahrungsbericht:
Es galt erstmal heraus zufinden welches Ubuntu in dem Subsystem verwendet wird.
Dazu verwenden wir folgendes Kommando:

# lsb_release -a

selection_019
Nun installieren wir erstmal Updates:
# sudo -i && apt-get update
gefolgt von eurem PW und dann dem Update:
selection_020
Als nächstes installieren wir das Icinga2 Repo fuer die anstehende installation von Icinga2.
# add-apt-repository ppa:formorer/icinga && apt-get update
selection_022
Nun legen wir mit der Datenbank los:

# apt-get install mariadb-server mariadb-client -y

Es muss hiernach das Passwort für den MySQL Root Benutzer angelegt werden.
# /etc/init.d/mysql start
# mysql_secure_installation

Login zu Mariadb:
# mysql -p
Anlegen der Icinga-IDO Datenbank:
selection_027
# create database icinga;
Festlegen des IDO Benutzers:
# grant all on icinga.* to 'icinga'@'localhost' identified by 'icinga';
# apt-get install nagios-plugins-all -y

Damit haben wir die Plugin-Checks installiert aber es fehlt uns noch der Webserver :
Dem widmen wir uns nun :
# apt-get install apache2
gefolgt von der simplen installation von icinga2;
# apt-get install icinga2
selection_031
Wir starten nun erstmal den Icinga2 Service:
# /etc/init.d/icinga2 start
Nun brauchen wir natuerlich auch den Rest 🙂
# apt-get install icingaweb2 icingacli icinga2-ido-mysql
Nach dem die Installation durchgelaufen ist editieren wir erstmal die IDO Konfig Datei:
selection_034
# vi /etc/icinga2/features-enabled/ido-mysql.conf
und kommentieren alle wichtigen eintraege ein und ändern Sie ggf. ab.
Wir müssen auch noch die die php.ini editieren:
# vi /etc/php5/apache2/php.ini
Wir suchen darin nach date.timzezone und tragen hier eine Sinnvolle Zeitzone ein.

apt-get install php5-gd php5-imagick

gefolgt von :
# /etc/init.d/httpd restart
Auch ein enablen der Commandpipe ist notwendig:
# icinga2 feature enable command
Fuer das Webfrontend benoetigen wir einen setup token
# icingacli setup token create
Der Webserver läuft schon , wir oeffen im Edge die folgende adresse
und benutzen den angeforderten Token.
Wir fuellen das Setup Sinnvoll aus 🙂
Ausserdem muss ggf. die iptables firewall eingetragen werden:
# iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
selection_054
Und erhalten zum Schluß ein laufendes Icinga2 welches im LSW installiert ist.
Ich hoffe ihr hattet bischen Spaß beim dem nachvollziehen oder nachbauen.
Ich freue mich über Feedback jeglicher Art.
Gruß
David

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

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
Lennart Betz
Senior Consultant

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.