Informationen zum Cassandra-Replikationsfaktor
Cassandra speichert Datenreplikate auf mehreren Knoten, um Zuverlässigkeit und Fehlertoleranz sicherzustellen. Die Replikationsstrategie für jeden Edge-Schlüsselbereich bestimmt die Knoten, auf denen Replikate platziert werden.
Die Gesamtzahl der Replikate für einen Schlüsselbereich in einem Cassandra-Cluster wird als Replikationsfaktor des Schlüsselraums bezeichnet. Ein Replikationsfaktor von 1 bedeutet, dass im Cassandra-Cluster nur eine Kopie jeder Zeile vorhanden ist. Ein Replikationsfaktor von zwei bedeutet, dass es zwei Kopien jeder Zeile gibt, wobei sich jede Kopie auf einem anderen Knoten befindet. Alle Replikate sind gleich wichtig. Es gibt kein primäres oder Master-Replikat.
In einem Produktionssystem mit drei oder mehr Cassandra-Knoten in jedem Rechenzentrum ist der Standardreplikationsfaktor für einen Edge-Schlüsselraum drei. In der Regel sollte der Replikationsfaktor die Anzahl der Cassandra-Knoten im Cluster nicht überschreiten.
Verwenden Sie das folgende Verfahren, um das Cassandra-Schema anzusehen, das den Replikationsfaktor für jeden Edge-Schlüsselbereich zeigt:
- Melden Sie sich bei einem Cassandra-Knoten an.
- Führen Sie den folgenden Befehl aus:
/opt/apigee/apigee-cassandra/bin/cassandra-cli -h $(hostname -i) <<< "show schema;"
Dabei wird
$(hostname -i)in die IP-Adresse des Cassandra-Knotens aufgelöst. Alternativ können Sie$(hostname -i)durch die IP-Adresse des Knotens ersetzen.
Für jeden Tastenbereich wird die Ausgabe im folgenden Format angezeigt:
create keyspace kms
with placement_strategy = 'NetworkTopologyStrategy'
and strategy_options = {dc-1 : 3}
and durable_writes = true;
Sie sehen, dass für Rechenzentrum 1, dc-1, bei einer Installation mit drei Cassandra-Knoten der Standardreplikationsfaktor für den Schlüsselbereich kms drei beträgt.
Wenn Sie dem Cluster zusätzliche Cassandra-Knoten hinzufügen, hat dies keine Auswirkungen auf den Standardreplikationsfaktor.
Wenn Sie beispielsweise die Anzahl der Cassandra-Knoten auf sechs erhöhen, aber den Replikationsfaktor bei drei belassen, sorgen Sie nicht dafür, dass alle Cassandra-Knoten eine Kopie aller Daten haben. Wenn ein Knoten ausfällt, bedeutet ein höherer Replikationsfaktor eine höhere Wahrscheinlichkeit, dass die Daten auf dem Knoten auf einem der verbleibenden Knoten vorhanden sind. Der Nachteil eines höheren Replikationsfaktors ist eine höhere Latenz bei Datenschreibvorgängen.
Informationen zur Cassandra-Konsistenzebene
Die Cassandra-Konsistenzebene ist definiert als die Mindestanzahl von Cassandra-Knoten, die einen Lese- oder Schreibvorgang bestätigen müssen, bevor der Vorgang als erfolgreich betrachtet werden kann. Verschiedene Konsistenzebenen können verschiedenen Edge-Tastenkombinationen zugewiesen werden.
Wenn für Lese- und Schreibvorgänge eine Verbindung zu Cassandra hergestellt wird, verwenden Knoten des Message Processor und des Management Servers in der Regel den Cassandra-Wert LOCAL_QUORUM, um die Konsistenzebene für einen Schlüsselbereich anzugeben. Einige Schlüsselräume sind jedoch so definiert, dass eine Konsistenzebene von 1 verwendet wird.
Der Wert von LOCAL_QUORUM für ein Rechenzentrum wird so berechnet:
LOCAL_QUORUM = (replication_factor/2) + 1
Wie oben beschrieben, beträgt der Standardreplikationsfaktor für eine Edge-Produktionsumgebung mit drei Cassandra-Knoten drei. Daher gilt der Standardwert von LOCAL_QUORUM = (3/2) + 1 = 2 (der Wert wird auf eine Ganzzahl abgerundet).
Mit LOCAL_QUORUM = 2 müssen mindestens zwei der drei Cassandra-Knoten im Rechenzentrum auf einen Lese-/Schreibvorgang reagieren, damit der Vorgang erfolgreich ist. Bei einem Cassandra-Cluster mit drei Knoten könnte der Cluster daher tolerieren, dass ein Knoten pro Rechenzentrum ausgefallen ist.
Durch Angabe der Konsistenzstufe als LOCAL_QUORUM vermeidet Edge die Latenz, die bei der Validierung von Vorgängen über mehrere Rechenzentren hinweg erforderlich ist. Wurde in einem Schlüsselraum der Cassandra-Wert QUORUM als Konsistenzebene verwendet, müssen Lese-/Schreibvorgänge in allen Rechenzentren validiert werden.
So rufen Sie die Konsistenzstufe auf, die von den Edge Message Processor- oder Management Server-Knoten verwendet wird:
- Melden Sie sich bei einem Message Processor-Knoten an.
- Wechseln Sie zum Verzeichnis /opt/apigee/edge-message-processor/conf :
cd /opt/apigee/edge-message-processor/conf
- Für Schreibkonsistenz:
grep -ri "write.consistencylevel" *
- Für Lesekonsistenz:
grep -ri "read.consistencylevel" *
- Melden Sie sich im Verwaltungsserver-Knoten an.
- Wechseln Sie zum Verzeichnis /opt/apigee/edge-management-server/conf:
cd /opt/apigee/edge-management-server/conf
- Wiederholen Sie die Schritte 3 und 4.
Wenn Sie dem Cluster zusätzliche Cassandra-Knoten hinzufügen, wird die Konsistenzebene nicht beeinflusst.