Pingu
Computer MySQL PostgreSQL Books Publications
Spielereien Kanu Business TopoDB POI Klettersteigen History TransPool Thermal Baden Brokenstuben Goldwaschen
Blog Contact
Shinguz
Google
/ch/open

Cluster Test

Vorwort

Wir sehen immer wieder, dass Kunden Galera Cluster oder InnoDB Cluster implementieren ohne sie sauber zu testen und zu verstehen wie man Probleme mit dem Cluser richtig löst. Diese kurze Anleitung soll Ideen geben, wie man einen DB Cluster testet, um sein Verhalten kennen zu lernen…

Galera Cluster und InnoDB Cluster Tests

Nach jedem Testpunkt ist der Cluster zuerst wieder in einen sauberen, stabilen Zustand zu überführen, bevor mit dem nächsten Punkt begonnen wird.

  1. Ein Cluster-Test sollte immer unter Schreiblast erfolgen. Ein idelnder Cluster oder ein Cluster, auf welchem nur gelesen wird entspricht nicht der Realiät und zeigt nicht die möglichen auftretenden Probleme auf. Ein ein einfacher Schreiblast-Generator ist unser bekannter insert_test.sh.

  2. Knoten stop und wieder starten, sowohl Leseknoten als auch Schreibknoten. Schauen, wie sich die Anwendung (= insert_test.sh) dabei verhält!

  3. Ein Rolling Cluster Restart durchführen und Anwendung dabei beobachten, wie sie sich verhält.

  4. Ein Cluster Shutdown durchführen und Cluster neu bootstrappen (letzen Knoten zuerst!). Idelerweise von jedem Knoten einmal.

  5. Ein Cluster Shutdown durchführen und Cluster neu bootstrappen, diesmal nicht vom letzten Knoten!

  6. Kabel auf einem Knoten ziehen. Kann in in virtuellen Umgebungen mittels Firewall-Regeln erfogen:
    $ /sbin/iptables --insert INPUT --protocol tcp --match multiport --dports 4567,4568,4444 -j REJECT ; /sbin/iptables --insert OUTPUT --protocol tcp --match multiport --dports 4567,4568,4444 -j REJECT
    Nach einiger Zeit Kabel wieder einstecken:
    $ /sbin/iptables -F

  7. Kabel auf mehreren Knoten ziehen und nach einiger Zeit wieder einstecken.

  8. Kabel auf mehreren Knoten ziehen und nach einiger Zeit in umgekehrter Reihenfolge wieder einstecken

  9. Eine DB Maschine rebooten, alle Maschinen zusammen rebooten (simuliert einen unkontrollierten VM Host Fehler). Kann auch mit: $ kill -s STOP $(pidof mysqld mariadbd) und $ kill -s CONT $(pidof mysqld mariadbd) simuliert werden.

  10. Knoten mit $ kill -9 killen und schauen, was passiert.

  11. Kabel auf erstem Knoten ziehen, warten, Kabel auf zweitem Knoten ziehen, warten, Kabel vom ersten Knoten wieder einstecken, zweiten Knoten stoppen, Kabel von zweiten Knoten wieder einstecken. Anschliessend Befehl $ rm -rf /var/lib/mysql auf zweitem Knoten ausführen. Dann Cluster wieder OHNE Neustart reparieren…

  12. Hybernaten der Maschine hilft manchmal, heftige Galera Cluster Probleme zu provozieren.

  13. SST erzwingen und Dauer des SST messen. Aus DB Error Log herauslesen, wie man SST und IST unterscheiden kann.

  14. SST Methoden rsync und mariabackup testen und schauen, wie sich die Anwendung (= insert_test.sh) verhält.

  15. VM Snapshot durchführen, nur auf einer Maschine, dann auf zwei Maschinen gleichzeitig.

  16. Spalte ändern (non instantaneous operation) auf einem anderen Schema als test ändern. Z. B. SQL> ALTER TABLE test.test MODIFY COLUMN data VARCHAR(255); wobei die Applikation (insert_test.sh) noch läuft. Applikation dabei beobachten…

  17. Volles Logisches Backup (mariadb-dump) wieder in den Cluster zurückspielen (welche Varianten gibt es und was sind die Vor- und Nachteile?)

  18. Volles Physisches Backup (mariadb-backup) wieder in den Cluster zurückspielen (welche Varianten gibt es und was sind die Vor- und Nachteile?)

  19. Point-in-Time-Recovery ausführen (welche Varianten gibt es und was sind die Vor- und Nachteile?)

  20. Partielles logisches Backup (Schema) wieder in den Cluster zurückspielen.

  21. Partielles physisches Backup (Schema) wieder in den Cluster zurückspielen.

  22. Point-in-Time-Recovery für dieses Schema ausführen.

  23. Partielles logisches Backup (Tabelle) wieder in den Cluster zurückspielen.

  24. Partielles physisches Backup (Tabelle) wieder in den Cluster zurückspielen.

  25. Point-in-Time-Recovery für diese Tabelle ausführen.

  26. Proxy-Ausfall (MariaDB MaxScale / ProxySQL / HAproxy / Galera Load Balance / MySQL Router) simulieren.

  27. Knoten im Proxy drainen (trocken legen) als Vorbereitung für anschliessendes Stoppen des Knotens.

  28. Knoten aus dem Proxy rausnehmen als Vorbereitung für anschliessendes Stoppen des Knotens.

  29. Rolle des Knotens im Proxy von Reader/Primary/Master auf Writer/Secondary/Slave umstellen und umgekehrt.

  30. Proxy-Konfigurationsänderungen auf beide Proxys synchronisieren (Peering).

  31. Proxy-Protokoll im Proxy und auf den Cluster-Knoten aktivieren.

  32. SST ausführen während Applikation über Proxy auf Cluster schreibt. Reagiert der Proxy richtig auf Donor/Joiner-Statuswechsel?