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.
NETWAYS Blog
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
- https://www.percona.com/blog/2015/08/20/optimizing-pxc-xtrabackup-state-snapshot-transfer/
- https://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-provider-index.html
- https://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-system-index.html
- https://severalnines.com/blog/understanding-gcache-galera
- https://github.com/madler/pigz
- https://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_option_reference.html
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)');
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 🙂