So lesen Sie den Zustand eines Galera-Clusters in fünf Statusvariablen

Ein Galera-Cluster (Percona XtraDB Cluster oder MariaDB Galera) kann aus Sicht der Anwendung völlig in Ordnung aussehen, während es im Stillen auf zwei Beinen läuft, sich selbst ausbremst oder einen Knoten mitführt, der für die Rückkehr eine vollständige Kopie brauchen wird. Jeder dieser Zustände ist in einer Handvoll Statusvariablen sichtbar. So lesen wir sie, und das sagt Ihnen jede einzelne.

Das Problem: «es beantwortet Abfragen» ist kein Gesundheitscheck

Das meiste Monitoring für eine geclusterte Datenbank prüft dasselbe, was es für einen einzelnen Server geprüft hat: Ist Port 3306 offen, liefert SELECT 1 ein Ergebnis. Ein Galera-Knoten, der aus der Primary Component herausgefallen ist, nimmt weiterhin Verbindungen an. Ein Knoten, der synced ist, aber Schreibvorgänge zu langsam anwendet, beantwortet weiterhin Reads. Ein Cluster aus drei Knoten, das still zu einem Cluster aus zwei geworden ist, liefert die Website weiterhin aus, bis zu dem Moment, in dem der nächste Knoten wegfällt und das Quorum verloren ist.

Das Cluster weiß all das über sich selbst. Sie müssen es nur fragen.

Die eine Abfrage, die Sie auf jedem Knoten ausführen

SHOW GLOBAL STATUS WHERE Variable_name IN (
  'wsrep_cluster_status',
  'wsrep_cluster_size',
  'wsrep_local_state_comment',
  'wsrep_ready',
  'wsrep_cluster_state_uuid',
  'wsrep_flow_control_paused',
  'wsrep_local_recv_queue_avg',
  'wsrep_local_send_queue_avg',
  'wsrep_local_cert_failures',
  'wsrep_local_bf_aborts'
);

Führen Sie sie auf jedem Mitglied aus, nicht nur auf dem, das Ihr Load Balancer zufällig erreicht. Mehrere dieser Werte sind lokal für den Knoten, und die interessanten Fehler sind die, bei denen die Knoten nicht übereinstimmen.

Mitgliedschaft: Ist dieser Knoten wirklich Teil des Clusters?

wsrep_cluster_status muss Primary sein. Alles andere (Non-Primary, Disconnected) bedeutet, dass dieser Knoten den Kontakt zur Mehrheit verloren hat und sich weigern wird, konsistente Daten auszuliefern. Wenn Ihr Gesundheitscheck diesen Wert nicht ansieht, kann ein abgetrennter Knoten weiter Verkehr erhalten.

wsrep_cluster_size muss der Zahl der Knoten entsprechen, die Sie gebaut haben. Das ist die Variable, die das «Laufen auf zwei Beinen» erwischt. Ein Cluster aus drei Knoten, das zwei meldet, liefert weiterhin aus, hat weiterhin Quorum und keinerlei Toleranz mehr übrig. Alarmieren Sie als Warnung in dem Moment, in dem der Wert unter die geplante Größe fällt, nicht erst, wenn er bei eins ankommt.

wsrep_local_state_comment sollte Synced lauten. Donor/Desynced bedeutet, dass der Knoten einen Joiner versorgt und möglicherweise gebremst ist. Joining und Joined bedeuten, dass er noch aufholt. Ein Knoten in jedem anderen Zustand als Synced sollte von Ihrem Proxy aus dem Read-Pool genommen werden, bis er zurück ist.

wsrep_cluster_state_uuid muss auf jedem Knoten identisch sein. Zwei verschiedene Werte bedeuten, dass Sie zwei Cluster haben, von denen jedes glaubt, das Cluster zu sein. Das passiert nur, nachdem jemand den falschen Knoten gebootstrappt hat, weshalb es sich nach jeder manuellen Wiederherstellung lohnt, nachzusehen.

wsrep_ready bestätigt lediglich, dass der Knoten Abfragen annimmt. Steht dort OFF, sagen Ihnen die anderen Werte, warum.

Performance: Hält sich das Cluster selbst zurück?

Die Replikation in Galera beruht auf Zertifizierung: Jeder Knoten muss zustimmen, dass ein Write Set nicht in Konflikt steht, bevor es committet wird. Das macht das Cluster so schnell wie seinen langsamsten Applier, und Galera setzt das mit Flow Control durch.

wsrep_flow_control_paused ist der Anteil der Zeit seit dem letzten FLUSH STATUS, in dem die Replikation pausiert war, weil irgendein Knoten nicht mithalten konnte. Lesen Sie ihn als Prozentsatz. Nahe null ist gesund. Alles, was dauerhaft über wenigen Prozent liegt, bedeutet, dass Schreibvorgänge auf einen langsamen Knoten warten, und die Schreiblatenz Ihrer Anwendung zahlt dafür. Flushen, ein bekanntes Intervall warten, erneut lesen, damit die Zahl die Gegenwart beschreibt und nicht den letzten Monat.

wsrep_local_recv_queue_avg sagt Ihnen, welcher Knoten langsam ist. Ein Knoten, dessen durchschnittliche Empfangswarteschlange deutlich über null liegt, ist derjenige, der Flow Control auslöst. Meist ist die Ursache lokal: langsamerer Storage, ein lauter Nachbar, ein lang laufender Report oder zu wenige Applier-Threads (wsrep_applier_threads, oder wsrep_slave_threads in älteren Versionen).

Ein steigender wsrep_local_send_queue_avg zeigt in die andere Richtung: Dieser Knoten hat Mühe, seine eigenen Write Sets zu senden, was meist Latenz oder Paketverlust im Netzwerk zwischen den Mitgliedern bedeutet. Das ist der Grund, warum Cluster-Mitglieder in dieselbe Fabric mit niedriger Latenz gehören, während Kopien an anderen Standorten über asynchrone Replikate laufen.

Konflikte: Schreiben Sie auf mehr als einen Knoten?

wsrep_local_cert_failures und wsrep_local_bf_aborts zählen Transaktionen, die zurückgerollt wurden, weil ein anderer Knoten eine widersprechende Änderung zuerst committet hat. Die Anwendung sieht sie als Deadlock-Fehler. Ein stetiges Rinnsal in einem Cluster, in dem jeder Knoten Schreibvorgänge annimmt, ist die Signatur von Multi-Writer-Konflikten, und WordPress- und E-Commerce-Plugins, die bei jedem Request dieselben Option- oder Counter-Zeilen aktualisieren, erzeugen sie in Mengen.

Die Lösung ist architektonisch, kein Tuning-Parameter: Senden Sie alle Schreibvorgänge an einen Knoten und verteilen Sie die Reads. Mit ProxySQL ist das eine einzige Zeile:

INSERT INTO mysql_galera_hostgroups
  (writer_hostgroup, backup_writer_hostgroup, reader_hostgroup,
   offline_hostgroup, active, max_writers, writer_is_also_reader,
   max_transactions_behind)
VALUES (10, 20, 30, 40, 1, 1, 1, 100);
LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;

max_writers = 1 wählt einen Writer, die anderen werden Reader und Backup-Writer, und max_transactions_behind lässt ProxySQL einen zurückfallenden Knoten automatisch aus dem Read-Pool nehmen. Sobald die Schreibvorgänge an einen Knoten gehen, sollten diese beiden Zähler nahezu stillstehen.

Wenn sich danach Redakteure beschweren, dass eine Speicherung beim Neuladen «verschwunden» ist, ging der Read an einen Knoten, der den Schreibvorgang noch nicht angewendet hatte. wsrep_sync_wait für diese Sitzungen zu setzen lässt den Read warten, bis der Knoten aufgeholt hat, gegen einen kleinen Latenzaufschlag.

Wiedereintritt: Kommt ein Knoten schnell oder langsam zurück?

Ein Knoten, der geht und zurückkehrt, erhält entweder die verpassten Write Sets aus dem Cache eines Donors (IST, inkrementell und schnell) oder eine vollständige Kopie des Datenbestands (SST, langsam und schwer für den Donor). Welches von beiden Sie bekommen, hängt davon ab, ob der Write-Set-Cache des Donors, gcache.size in wsrep_provider_options, noch alles enthält, was der Joiner verpasst hat.

Sie können ihn anhand der eigenen Zähler des Clusters dimensionieren. Lesen Sie wsrep_replicated_bytes und wsrep_received_bytes im Abstand einer Stunde. Die Summe der Differenzen ist ungefähr das Write-Set-Volumen pro Stunde. Multiplizieren Sie mit dem längsten Wartungsfenster, das Sie erwarten, geben Sie eine Reserve dazu, und das ist die gcache, die Sie brauchen. Ein Knoten kann dann gepatcht, neu gestartet oder stundenlang für Hardware-Arbeiten angehalten werden und trotzdem inkrementell zurückkehren.

Quorum: die Arithmetik hinter der «Drei»

Quorum ist eine strikte Mehrheit. Drei Mitglieder verkraften den Verlust von einem. Vier Mitglieder verkraften ebenfalls nur eins, weil zwei von vier keine Mehrheit sind, der vierte Knoten kauft also Kapazität, aber keine Ausfallsicherheit. Zwei Mitglieder verkraften nichts: Verlieren sie einander aus den Augen, bleiben beide stehen. Wenn Sie wirklich nur zwei Datenknoten haben, ergänzen Sie den Galera-Arbitrator (garbd) auf einem dritten, unabhängigen Host, damit weiterhin eine Mehrheit existiert.

Dieselbe Arithmetik gilt dafür, wo die Mitglieder leben. Drei Knoten auf einem Host, oder drei Knoten, deren Daten auf einem Storage-Array liegen, sind eine Failure Domain mit drei Namen. In Kubernetes kombinieren Sie hartes Pod-Anti-Affinity mit einem PodDisruptionBudget von minAvailable: 2, damit ein rollierendes Knoten-Update nie zwei Mitglieder gleichzeitig nehmen kann.

Was Sie diese Woche in Ihrem eigenen Cluster prüfen sollten

• Jeder Knoten meldet Primary, Synced, dieselbe State-UUID und die Clustergröße, die Sie geplant haben.
• Ihr Gesundheitscheck und Ihr Proxy verwenden beide diese Werte, nicht nur einen TCP-Connect.
• wsrep_flow_control_paused, über ein frisches Intervall gemessen, liegt nahe null.
• Die Zertifizierungsfehler steigen nicht. Wenn doch, landen Schreibvorgänge auf mehr als einem Knoten.
• Ihre gcache deckt Ihr längstes geplantes Wartungsfenster ab.
• Kein Paar von Mitgliedern teilt sich einen Host, ein Array oder (in Kubernetes) eine Disruption ohne Budget.

Ein Galera-Cluster, das so gelesen wird, überrascht selten jemanden. Wenn Ihres es tut, sehen wir es uns gern an.

cta: Mit einem Ingenieur sprechen

Related

• /what-we-do/data-web/clustered-databases/
• /what-we-do/data-web/database-replication/
• /what-we-do/data-web/high-availability-platforms/