In diesem Abschnitt werden die regelmäßigen Wartungsaufgaben für Cassandra beschrieben.
Wartung gegen Entropie
Die Apache Cassandra-Ringknoten müssen regelmäßig gewartet werden, um die Konsistenz in allen Knoten. Verwenden Sie den folgenden Befehl, um diese Wartung durchzuführen:
apigee-service apigee-cassandra apigee_repair -pr
Apigee empfiehlt beim Ausführen dieses Befehls Folgendes:
- Ausführung auf jedem Cassandra-Knoten (in allen Regionen und Rechenzentren).
Führen Sie die Ausführung jeweils auf einem Knoten aus, um für Konsistenz auf allen Knoten im Ring zu sorgen. Das gleichzeitige Ausführen von Reparaturjobs auf mehreren Knoten die Gesundheit von Cassandra beeinträchtigen können.
Um zu prüfen, ob ein Reparaturjob auf einem Knoten erfolgreich abgeschlossen wurde, sehen Sie in der
system.log
-Datei für einen Eintrag mit der UUID der letzten Reparatursitzung und dem Satz „Sitzung erfolgreich abgeschlossen“. Hier ist ein Beispiel für einen Logeintrag:INFO [AntiEntropySessions:1] 2015-03-01 10:02:56,245 RepairSession.java (line 282) [repair #2e7009b0-c03d-11e4-9012-99a64119c9d8] session completed successfully" Ref: https://support.datastax.com/hc/en-us/articles/204226329-How-to-check-if-a-scheduled-nodetool-repair-ran-successfully
- Führen Sie das Tool in Zeiträumen mit relativ geringer Arbeitslast aus (das Tool belastet das System).
- Ausführung mindestens alle sieben Tage, um Probleme im Zusammenhang mit Vergessene Löschvorgänge.
- Führen Sie ihn an verschiedenen Tagen auf verschiedenen Knoten aus oder planen Sie ihn so, mehrere Stunden zwischen der Ausführung auf jedem Knoten.
- Verwenden Sie die Option
-pr
(Partitionerbereich), um den Bereich des primären Partitionierers anzugeben des Knotens.
Wenn Sie die JMX-Authentifizierung für Cassandra aktiviert haben,
Sie müssen beim Aufrufen von nodetool
den Nutzernamen und das Passwort angeben. Beispiel:
apigee-service apigee-cassandra apigee_repair -u username -pw password -pr
Sie können auch den folgenden Befehl ausführen, um die unterstützten Optionen von apigee_repair:
zu prüfen
apigee-service apigee-cassandra apigee_repair -h
Hinweis:apigee_repair
ist ein Wrapper für die Nodetool-Reparatur von Cassandra.
der vor der Cassandra-Reparatur weitere Prüfungen durchführt.
Weitere Informationen finden Sie in den folgenden Ressourcen:
Wartung von Logdateien
Cassandra-Logs werden im Verzeichnis /opt/apigee/var/log/cassandra
auf
für jeden Knoten. Standardmäßig können maximal 50 Protokolldateien mit jeweils einer maximalen Größe von 20 MB
erstellt; Sobald dieses Limit erreicht ist, werden ältere Logs gelöscht, wenn neuere Logs erstellt werden.
Wenn Sie feststellen sollten, dass Cassandra-Protokolldateien übermäßig viel Speicherplatz belegen, können Sie den für Protokolldateien zugewiesener Speicherplatz, indem Sie die Einstellungen von log4j bearbeiten.
/opt/apigee/customer/application/cassandra.properties
bearbeiten um die folgenden Eigenschaften festzulegen. Sollte die Datei nicht vorhanden sein, erstellen Sie sie:conf_logback_maxfilesize=20MB # max file size conf_logback_maxbackupindex=50 # max open files
- Starten Sie Cassandra mit dem folgenden Befehl neu:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
Wartung von Speicherplatz
Sie sollten die Cassandra-Laufwerksauslastung regelmäßig überwachen, um sicherzustellen, ist jedes Laufwerk kostenlos. Wenn die Laufwerksauslastung über 50 % steigt, sollten Sie Fügen Sie mehr Speicherplatz hinzu, um den belegten Anteil zu reduzieren.
Cassandra führt automatisch die folgenden Vorgänge aus, um ihre eigene Laufwerksauslastung:
- Löschung von Authentifizierungstokens, wenn Tokens ablaufen. Es kann jedoch sein, einige Wochen, um den von den Tokens belegten Festplattenspeicher freizugeben. Konfiguration. Wenn das automatische Löschen nicht ausreicht, Ausreichender Speicherplatz. Wenden Sie sich an den Support, um mehr über das manuelle Löschen von Tokens zur Wiederherstellung zu erfahren. Leerzeichen.
Hinweis zur Datenverdichtung: Ab Edge für Private Cloud 4.51.00 werden neue Installationen von Apigee Cassandra erstellt Schlüsselbereiche mit der <ph type="x-smartling-placeholder"></ph> Verdichtungsstrategie auf einer bestimmten Stufe.
Installationen älterer Versionen von Edge für Private Cloud, die auf aktualisiert wurden Private Cloud 4.51.00 wird weiterhin die bisherige Verdichtungsstrategie beibehalten. Wenn die vorhandene „SizeTieredCompactionStrategy“ ist, empfehlen wir, LeveledCompactionStrategy, die eine bessere Laufwerksauslastung ermöglicht.
Hinweis:Wenn Cassandra Datenverdichtungen ausführt, kann dies einige CPU-Zyklen in Anspruch nehmen.
und das Gedächtnis. Die Ressourcenauslastung sollte sich jedoch nach Abschluss der Verdichtungen wieder normalisieren.
Sie können den Befehl 'Nodetool compactionstats'
auf jedem Knoten ausführen.
um zu prüfen, ob die Verdichtung ausgeführt wird. Die Ausgabe von compactionstats
informiert Sie, wenn es
stehen für die auszuführende Verdichtungen und die geschätzte Zeit für den Abschluss.