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
Support 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 Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, 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 Development

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.

OSDC 2016 – 8th year of glory

Time flies – 8 years Open Source Datacenter Conference (OSDC) already and now the 3rd time in lovely Berlin.
Kicking off with Dawn Foster’s keynote on Open Source – A job and an adventure gave an interesting insight into Open Source careers and living the spirit. As we do at NETWAYS since 1995 inviting everyone onto our journey and happily organising conferences for talks, chats & some drinks together.
And remember …


Next up was Kris talking about Another 7 tools for your #devops stack which is always fun to watch. I couldn’t decide whether to join him or go for Mike Elsmore on NoSQL is a lie … though Daniela approached me and said “go for Mike, it is funny”. And so it was in combination with the interesting technical questions asked.


Tough decisions already in the morning – we’re using CoreOS at NETWAYS too and so I could join Jonathan Bulle on rkt and Kubernetes: What’s new with Container Runtimes and Orchestration … or learning something new, moving away from Puppet and learn about Salt – A Scalable Systems Management Solution for Datacenters by Sebastian Meyer.
A pretty hard one also for the presenters as these talks ended right before lunch break – and as you might know already, food is always so delicious at OSDC.


Finding a place to chill after lunch (oh, it was delicious) should it now be What’s wrong with my Puppet? by Felix Frank or would I go for learning about some monitoring tasks with Hello Redfish, Goodbye IPMI – The Future of System Management in the Data Center with Werner Fischer. I guess I’m more with Puppet these days, less monitoring admin – and the live demo stuff somehow failed but nice to see David Schmitt helping out.


Ever since Elastic announced their Beats toolstack I wanted to learn more about it. I was pretty sad that I couldn’t join Elasticon earlier this year. So I was eagerly waiting for Monica Sarbu telling me more about Unifying Log Management and Metrics Monitoring with the Elastic Beats.


Having the Icinga stack in mind with open APIs and such, this shed interesting insights on how to further push integration with Elastic forward. Oh and I definitely need to learn Golang to hack my own beats based on the libbeat library.


Continuous Integration in Data Centers – Further 3 Years Later with Michael Prokop sounded interesting as well, especially when it comes to Jenkins and Docker integration. Luckily all talks are recorded and made available later in the conference archive so I decided to go for Elastic Beats this time.


Martin Schütte gave interesting insights into Terraform: Config Management for Cloud Services. This tool fits into the devops stack HashiCorp has been building over the last years, including Vagrant, Atlas and Otto. MySQL clusters are overly complicated in my (developer) opinion so I didn’t go for MySQL-Server in Teamwork – Replication and Galera Cluster presented by Jörg Brühe. Again one for the archive watchers 🙂


ChatOps is becoming more important these days. I’ve already seen Martin’s great talk at Icinga Camp Berlin earlier this year – especially his live demo talking to the Icinga 2 API which makes me a proud developer. ChatOps – Collaborative Communication (or: You cannot not communicate) is definitely something everyone needs to consider and play around with. Especially when it is Open Source.


Heading over from Austria left behind my DNS related past though I’m trying to keep with it. Especially since Jan-Piet is talking about DNS for Developers aka “Everything is a freaky DNS problem” 😉

Evening event

Now that we’ve learnt and discussed so much on the first day we are ready for the evening event. This time it located at Umspannwerk Ost which looks nice indeed. Looking forward to delicious food again and later on, some G&T with the OSDC gang 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Weekly Snap: Galera & Icinga 2 Clusters, Puppet for Tomcat & Nagios

weekly snap11 – 15 August featured clusters, Puppet automation and a new OSMC workshop.
Eva counted 106 days to the OSMC with Bernd and Sasha’s talk on how “Puppet automatically configures Nagios”.
Bernd followed by announcing a new Advanced Windows Monitoring workshop on NSClient++ to be held by Michael Medin at this year’s OSMC.
On clusters, Enrico looked at Galera as Michael gave an update on his work with Icinga 2 cluster vagrant boxes and the various Icinga 2 webinars and training courses.
Finally, Lennart shared his Puppet module for Tomcat installation and configuration.