Cassandra: Wartung

9

Ich bin unerfahren mit Cassandra, habe aber einige Erfahrungen mit SQL-basierten relationalen Datenbanken.

Ich konnte keine Best-Practice-Informationen zur Wartung von Cassandra nach der Bereitstellung finden. Muss die Datenbank VACUUMIERT werden? Ich sollte denken, dass Lese- / Schreiblasten eine Fragmentierung im Speicher verursachen.

Oder allgemeiner: Was sind die Best Practices für die Aufrechterhaltung einer Cassandra-Produktionsbereitstellung? Was muss in regelmäßigen Abständen getan werden, um den Zustand des Systems zu erhalten? Das Betriebshandbuch behandelt diesen Aspekt wirklich nicht.

Vielen Dank.

Mayur Patel
quelle
Okay, ich verstehe jetzt, dass die Verdichtung eine große Sache ist und automatisch abläuft. Gibt es jedoch noch andere Sorgen, wenn Sie einen Cluster über einen längeren Zeitraum unter Linux ausführen?
Mayur Patel

Antworten:

14

Im Allgemeinen kann ein gut gestalteter Cluster JAHRE lang leben, ohne berührt zu werden. Ich hatte Cluster, die jahrelang ohne Probleme liefen. Hier sind jedoch einige Richtlinien:

Überwachung ist enorm wichtig:

1) Überwachen Sie die Latenzen. Verwenden Sie opscenter oder Ihre bevorzugten Metrik-Tools, um die Latenzen zu verfolgen. Steigende Latenzen können Anzeichen für Probleme sein, einschließlich GC-Pausen (häufiger bei Lese-Workloads als bei Schreib-Workloads), stabile Probleme und dergleichen.

2) Überwachung der stabilen Anzahl. Die Anzahl der SSTables erhöht sich, wenn Sie die Komprimierung überschreiten (jede sstable wird genau einmal geschrieben - Löschvorgänge werden durch Kombinieren alter sstables zu neuen sstables durch Komprimierung behandelt).

3) Überwachen Sie Änderungen des Knotenstatus (nach oben / unten usw.). Wenn Knoten flattern, untersuchen Sie dies, da dies nicht normal ist.

4) Behalten Sie den Überblick über Ihre Festplattennutzung - traditionell müssen Sie unter 50% bleiben (insbesondere, wenn Sie die STCS-Komprimierung verwenden).

Es gibt einige grundlegende Dinge, die Sie regelmäßig tun sollten und nicht tun sollten:

1) Nicht explizit ausführen nodetool compact. Sie erwähnen, dass Sie es getan haben, es ist nicht tödlich, aber es erzeugt sehr große Ställe, die dann weniger wahrscheinlich an der zukünftigen Verdichtung teilnehmen. Sie müssen es nicht unbedingt weiter ausführen, aber manchmal kann es hilfreich sein, gelöschte / überschriebene Daten zu entfernen.

2) nodetool repairwird normalerweise alle gc_grace_seconds(standardmäßig 10 Tage) empfohlen . Es gibt Workloads, bei denen dies weniger wichtig ist. Der Hauptgrund für die Reparatur besteht darin, sicherzustellen, dass Löschmarkierungen ( tombstones) übertragen werden, bevor sie ablaufen (sie leben gc_grace_seconds, wenn ein Knoten zum Zeitpunkt des Löschens ausgefallen ist , werden diese Daten möglicherweise wieder lebendig ohne die Reparatur!). Wenn Sie keine Löschvorgänge ausführen und mit ausreichender Konsistenz abfragen (z. B. Lesen und Schreiben bei QUORUM), können Sie tatsächlich ein Leben ohne Reparatur führen.

3) Wenn Sie reparieren möchten, sollten Sie eine inkrementelle Reparatur in Betracht ziehen und jeweils kleine Bereiche reparieren.

4) Verdichtungsstrategien sind wichtig - sehr viel. STCS eignet sich hervorragend zum Schreiben, LCS eignet sich hervorragend zum Lesen. DTCS hat einige Macken.

5) Datenmodelle sind wichtig - genau wie RDBMS / SQL-Umgebungen Probleme bekommen, wenn nicht indizierte Abfragen große Tabellen treffen, kann Cassandra bei sehr großen Zeilen / Partitionen problematisch sein.

6) Schnappschüsse sind billig. Sehr billig. Fast augenblicklich, nur harte Links, kosten sie fast sofort keinen Speicherplatz. Verwenden Sie Snapshot, bevor Sie Versionen aktualisieren, insbesondere Hauptversionen.

7) Seien Sie vorsichtig beim Löschen. Wie in # 2 angedeutet, erstellt delete mehr Daten auf der Festplatte und gibt sie MINDESTENS nicht frei gc_grace_seconds.

Wenn alles andere schief geht:

Ich habe Artikel gesehen, die darauf hinweisen, dass Cassandra in Prod einen dedizierten Kopf für die Verwaltung von Clustern jeder Größe benötigt. Ich weiß nicht, dass dies unbedingt der Fall ist. Wenn Sie jedoch Bedenken haben, sollten Sie einen externen Berater (TheLastPickle, Pythian) beauftragen ) oder haben Sie einen Supportvertrag (Datastax), um sich zu beruhigen.

Jeff Jirsa
quelle
1
Jeff, es ist spät, hol etwas Schlafknospe!
Aaron
1
Mann, ich habe das Datum auf diesem nicht bemerkt. War wirklich spät, nicht wahr?
Jeff Jirsa
2

Nach Angaben der Cassandra Reparaturdokumentation , nodetool repairsollte in den folgenden Situationen ausgeführt werden:

  • Als bewährte Methode sollten Sie Reparaturen wöchentlich planen. Hinweis: Wenn Löschungen nie auftreten, sollten Sie dennoch regelmäßige Reparaturen einplanen. Beachten Sie, dass das Setzen einer Spalte auf null ein Löschen ist.
  • Während der Knotenwiederherstellung. Zum Beispiel, wenn ein Knoten nach einem Fehler wieder in den Cluster gebracht wird.
  • Auf Knoten mit Daten, die nicht häufig gelesen werden.
  • So aktualisieren Sie Daten auf einem Knoten, der ausgefallen ist.

Ich sollte denken, dass Lese- / Schreiblasten eine Fragmentierung im Speicher verursachen.

Daten in Cassandra "fragmentieren" nicht so, wie Sie denken. Löschvorgänge lösen jedoch die Platzierung von Grabsteinen aus, und der normale kompakte Vorgang entfernt die Grabsteine.

Ich verstehe jetzt, dass die Verdichtung eine große Sache ist und automatisch abläuft

Richtig. Ein DataStax-Mitarbeiter sagte mir, dass Sie es nach der compactmanuellen Ausführung immer manuell ausführen müssen. Der Grund dafür ist, dass die Komprimierung funktioniert, indem alle vorhandenen SSTABLES in einem Schlüsselbereich in eine einzige SSTABLE-Datei "komprimiert" werden. Möglicherweise enthält diese SSTABLE-Datei einige Spaltenfamilien, die klein sind und so lange dauern, bis sie über den Komprimierungsschwellenwert hinaus ansteigen, dass die Wahrscheinlichkeit, dass die automatische Komprimierung jemals wieder ausgeführt wird, sehr gering ist.

Stellen Sie im Wesentlichen sicher, dass Sie eine regelmäßige Strategie planen nodetool repair, niemals ausführen nodetool compactund eine Sicherungsstrategie implementieren (Snapshots, inkrementelle Sicherungen oder beides).

Aaron
quelle
Also, wenn ich gelaufen nodetool compactbin, bin ich für immer zum Scheitern verurteilt, wenn ich meinen Cluster nicht nuklear mache? Oder gibt es eine Möglichkeit, die automatische Verdichtung wieder in Betrieb zu nehmen?
2rs2ts
1
@ 2rs2ts Nun, nicht für "für immer". Sobald Sie eine manuelle Verdichtung durchgeführt haben ... "Ja", müssen Sie sie regelmäßig ausführen (wir würden dies immer direkt nach unserer wöchentlichen Reparatur tun). Klären Sie dies mit einem DataStax-Mitarbeiter, aber ich denke , wenn Sie ein Ereignis haben, das die SSTABLE-Dateien neu schreibt (z. B. ein Upgrade beim Ausführen upgradesstables), werden die Dinge möglicherweise genug zurückgesetzt, um Sie vor der "Hölle der manuellen Komprimierung " zu bewahren.
Aaron
Danke, macht wohl Sinn. Leider.
2rs2ts
1
Durch die automatische Komprimierung werden schließlich sstables erstellt, die groß genug sind, um auf natürliche Weise mit der Ausgabe von zu kompaktieren nodetool compact. Außerdem können Sie jetzt sstablesplit verwenden, um diesen unnatürlich großen sstable zu entfernen, sodass Sie das "rückgängig machen" können nodetool compact.
Jeff Jirsa