Seite wählen

NETWAYS Blog

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.

Request Tracker 4.4 Security Update and UTF8 issues with Perl’s DBD::Mysql 4.042

Last week, Best Practical announced that there are critical security fixes available for Request Tracker. We’ve therefore immediately pulled the patches from 4.4.2rc2 into our test stages and rolled them out in production.

Update == Broken Umlauts

One thing we did notice too late: German umlauts were broken on new ticket creation. Text was simply cut off and rendered subjects and ticket body fairly unreadable.

Encoding issues are not nice, and hard to track down. We rolled back the security fix upgrade, and hoped it would simply fix the issue. It did not, even our production version 4.4.1 now led into this error.
Our first idea was that our Docker image build somehow changes the locale, but that would have at least rendered „strange“ text, not entirely cut off. Same goes for the Apache webserver encoding. We’ve then started comparing the database schema, but was not touched in these regards too.

DBD::Mysql UTF8 Encoding Changes

During our research we learned that there is a patch available which avoids Perl’s DBD::mysql in version 4.042. The description says something about changed behaviour with utf8 encoding. Moving from RT to DBD::Mysql’s Changelog there is a clear indication that they’ve fixed a long standing bug with utf8 encoding, but that probably renders all other workarounds in RT and other applications unusable.

2016-12-12 Patrick Galbraith, Michiel Beijen, DBI/DBD community (4.041_1)
* Unicode fixes: when using mysql_enable_utf8 or mysql_enable_utf8mb4,
previous versions of DBD::mysql did not properly encode input statements
to UTF-8 and retrieved columns were always UTF-8 decoded regardless of the
column charset.
Fix by Pali Rohár.
Reported and feedback on fix by Marc Lehmann
(https://rt.cpan.org/Public/Bug/Display.html?id=87428)
Also, the UTF-8 flag was not set for decoded data:
(https://rt.cpan.org/Public/Bug/Display.html?id=53130)

 

Solution

Our build system for the RT container pulls in all required Perl dependencies by a cpanfile configuration. Instead of always pulling the latest version for DBD::Mysql, we’ve now pinned it to the last known working version 4.0.41.

 # MySQL
-requires 'DBD::mysql', '2.1018';
+# Avoid bug with utf8 encoding: https://issues.bestpractical.com/Ticket/Display.html?id=32670
+requires 'DBD::mysql', '== 4.041';

Voilá, NETWAYS and Icinga RT production instances fixed.

Conclusion

RT 4.4.2 will fix that by explicitly avoiding the DBD::Mysql version in its dependency checks, but older installations may suffer from that problem in local source builds. Keep that in mind when updating your production instances. Hopefully a proper fix can be found to allow a smooth upgrade to newer library dependencies.
If you need assistance with building your own Request Tracker setup, or having trouble fixing this exact issue, just contact us 🙂

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.

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 …

"be nice" #opensource @geekygirldawn #osdc pic.twitter.com/M8Q5YD9kPv

— Michael Friedrich (@dnsmichi) April 27, 2016


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.

Pikachu 😀 #osdc #awesome @ukmadlz pic.twitter.com/hYU8nY01Li

— Michael Friedrich (@dnsmichi) April 27, 2016


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.

@mjg59 your work featured at the rkt/kubernetes talk at #osdc pic.twitter.com/7NLEGcZvXf

— mika (@mikagrml) April 27, 2016


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.

#osdc trolling the demo gods, @felis_rex starts to live-code ruby in the shell pic.twitter.com/Jl4nkEXZjA

— David Schmitt (@dev_el_ops) April 27, 2016


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.

.@elastic #filebeat successor of #logstash forwarder @monicasarbu #osdc /mif pic.twitter.com/uWozj9xx4b

— netways (@Netways) April 27, 2016


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.

I need to learn golang for @elastic #libbeat – sounds awesome thx @monicasarbu #monitoring #osdc pic.twitter.com/TJwi8yDlbr

— Michael Friedrich (@dnsmichi) April 27, 2016


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.

Now @mikagrml w/ continuous delivery #osdc 🙂 /mif pic.twitter.com/zbssXyY6U5

— netways (@Netways) April 27, 2016


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 🙂

Now Martin Schütte is talking about @hashicorp #Terraform here at #osdc /be pic.twitter.com/Dck11TsW9t

— netways (@Netways) April 27, 2016


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.

Keep calm and love APIs #osdc pic.twitter.com/8hhYifp8Mp

— Christoph Mitasch (@CMitasch) April 27, 2016


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“ 😉

.@jpmens with #dns for developers #osdc /mif pic.twitter.com/LsutpiWshu

— netways (@Netways) April 27, 2016

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 🙂