4 Minuten Lesezeit (854 Worte)

Manchmal ist es ok, aus dem Takt zu geraten! – Backup eines Galera Clusters

Dienstag, 28. Mai 2024

Backups sind unverzichtbar. Zwar handelt es sich bei einem Galera Cluster um ein stabiles, zuverlässiges und ausgereiftes Produkt, welches vor vielen Fehlern und/oder Problemen schützt, aber eben nicht vor allen. Ein „DROP TABLE“ oder andere logische, durch Anwender sowie Administratoren verursachte Probleme können jederzeit stattfinden. Dieser Beitrag beschreibt ein Phänomen, bzw. eher ein Problem, welches wir häufiger bei den Backupkonzept unserer Kunden gesehen haben.

Notenkunde. Die Grundlagen von MySQL-Backups.

Bevor wir uns in die Details stürzen, ist es wichtig zu verstehen, dass Galera Cluster verschiedene Backup-Optionen bietet. Dazu gehören physikalische und logische Backups, des Weiteren Tools wie Percona XtraBackup und Mariabackup.

Physische Backups erfassen den gesamten Datenbankzustand auf Blockebene. Sie sind schnell und effizient, da sie die Integrität der Datenbankdateien bewahren. Werkzeuge wie Percona XtraBackup und Mariabackup sind beliebte Optionen für physische Backups in Galera Clustern.
Logische Backups sind nützlich, wenn Sie nur bestimmte Daten oder Tabellen sichern möchten. Dies ist besonders praktisch, wenn Sie nur einen Teil Ihrer Datenbank wiederherstellen müssen. Sie sind jedoch langsamer als physische Backups und benötigen mehr Speicherplatz.

Trotzdem werden logische Backups bei vielen Kunden immer noch gerne, auch zur vollumfänglichen Sicherung vollständiger Systeme sowie einzelner Schemata und Datenbanken eingesetzt. Das führt zu dem folgenden Problem/Phänomen.

Keinen Terz machen?

Ein Cluster besteht in der Regel, wie ein Dreiklang (Akkord), aus drei Knoten, die „in sync“ (synchronisiert) sein sollten. Dies kann sich bei einem Backup mit „mysqldump“ aber ggf. ändern, bzw. sollte sich das sogar ändern?

Schauen wir uns einmal den Status unseres Knotens „galera3“ in unserem Testcluster an, von dem wir später ein Backup via „mysqldump“ erstellen wollen:

mysql> show global status like 'wsrep_local_state_comment';
+---------------------------+--------+ 
| Variable_name             | Value  | 
+---------------------------+--------+ 
| wsrep_local_state_comment | Synced | 
+---------------------------+--------+ 
1 row in set (0.01 sec)

Gibt es Dissonanzen?

Viele unserer Kunden haben sich über Jahre mit ihren Backupkonzept via „mysqldump“ „angefreundet“. Die Schemata (Datenbanken) sind oftmals nicht besonders groß, das Konzept ist einfach (anwenderfreundlich) und erfüllt seinen Zweck. Oftmals waren diese Konzepte auch schon vor dem Einsatz des Clusters, zu Zeiten einer „Single-Instanz“ im Einsatz und wurden einfach fortgeführt.

„mysqldump“ muss zur „Erzwingung“ eines konsistenten Backups Sperren einsetzen (bei der reinen Nutzung der Engine InnoDB kann man diese mit dem Parameter „–single-transaction“ vermeiden). In einem Cluster müssten die Sperren jedoch clusterweit durchgesetzt werden, was die Verfügbarkeit des Systems natürlich deutlich beeinflusst: Niemand könnte in diesem Zustand DML-Operationen („Schreiben“) nutzen.

Doch was passiert wirklich auf diesen Konten? Wir simulieren diesen Prozess und versuchen, ähnlich wie „mysqldump“, Sperren auf unserem Cluster-Knoten einzufordern. Parallel beobachten wir das Error-Log des Knotens:

bash> tail -f /var/log/mysql/error.log & 
bash> mysql -uroot -proot --execute="flush tables with read lock; sleep(3); unlock tables" 

2024-03-20T08:12:45.570338Z 2345 [System] [MY-000000] [WSREP] L: Desyncing and pausing the provider 
2024-03-20T08:12:45.570723Z 0 [System] [MY-000000] [WSREP] P: Member 2.0 (galera3) desyncs itself from group 
… 
+----------+ 
| sleep(3) | 
+----------+ 
|        0 | 
+----------+ 
2024-03-20T08:12:48.581695Z 2345 [System] [MY-000000] [WSREP] L: Resuming and resyncing the provider 
2024-03-20T08:12:48.582401Z 2345 [System] [MY-000000] [WSREP] L: resume 
… 
2024-03-20T08:12:48.605685Z 2 [System] [MY-000000] [WSREP] L: Server galera3 synced with group

Wie zu erkennen ist, nimmt sich der Knoten für ein paar Sekunden aus dem Spiel. Dies kann man auch über die Status-Variablen abfragen:

mysql -uroot -proot --execute="flush tables with read lock; show global status like 'wsrep_local_state_comment'; unlock tables"
mysql: [Warning] Using a password on the command line interface can be insecure. 
+---------------------------+----------------+ 
| Variable_name             | Value          | 
+---------------------------+----------------+ 
| wsrep_local_state_comment | Donor/Desynced | 
+---------------------------+----------------+

D. h. im Rahmen unseres Backups wird der Knoten, der das Backup erstellt, für die entsprechende Zeit pausiert. Damit kann ein konsistentes Backup erstellt werden. Dies ist keine schlechte Nachricht: Das Backup funktioniert, der Rest des Clusters auch. Nur muss auch der Anwendung, bzw. den Anwendern, dieses Verhalten bewusst sein, denn während des Backupprozesses kann der entsprechende Knoten ggf. nicht wie gewohnt (und wie die anderen Knoten) verwendet werden.

Nach Noten spielen!

Gemäß der „reinen Lehre“ (Dokumentation [1]), ist dieses Verhalten ebenfalls, wenn auch in einer akademisch anderen Reihenfolge, zu befolgen.

Bevor z. B. ein logisches Backup mit „mysqldump“ (unter den oben beschriebenen Bedingungen) erstellt werden kann, soll der entsprechende Knoten „desynced“ werden. Dafür gibt es ein entsprechendes Kommando:

mysql -p -u root --execute "SET wsrep_desync = ON"

Erst im Anschluss an diesen Schritt kann der Dump erstellt werden. Abschließend ist der „desync“-Modus natürlich wieder zu deaktivieren (!).

mysql -p -u root --execute "SET wsrep_desync = OFF"

Mehr Harmonie

Einen Knoten für ein Backup aus dem Cluster „zu nehmen“ (wenn auch nur pausiert) kann eine Lösung sein. Richtig „fühlt“ sich dies jedoch nicht an. Besser wäre es aus unserer Sicht, das „erprobte“ Backupkonzept auf den Prüfstand zu erstellen. Die Alternativen sind vielfältig. Entweder bringt man eine physikalische („non-blocking“) Lösung in Betrieb oder aber man kombiniert den Cluster mit einem weiteren Backup-System (Server), der z. B. über eine asynchrone Replikation vom Cluster mit Daten versorgt wird.

Sie haben Fragen? Sprechen Sie mit uns über den Galera Cluster und/oder Ihre anderen MySQL/MariaDB Systeme. Wie freuen uns auf Sie.