Cassandra-Replikationsfaktor
Cassandra speichert Datenreplikate auf mehreren Knoten, um Zuverlässigkeit und Fehlertoleranz zu gewährleisten. Die Replikationsstrategie für jeden Edge-Keyspace 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üsselbereichs bezeichnet. Ein Replikationsfaktor von eins bedeutet, dass es im Cassandra-Cluster nur eine Kopie jeder Zeile gibt. 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 beträgt der Standardreplikationsfaktor für einen Edge-Schlüsselbereich drei. In der Regel sollte der Replikationsfaktor die Anzahl der Cassandra-Knoten im Cluster nicht überschreiten.
Gehen Sie so vor, um das Cassandra-Schema aufzurufen, das den Replikationsfaktor für jeden Edge-Schlüsselbereich zeigt:
- Melden Sie sich bei einem Cassandra-Knoten an.
- Führen Sie dazu diesen 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. Sie können$(hostname -i)auch durch die IP-Adresse des Knotens ersetzen.
Für jeden Keyspace wird eine 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, der Standardreplikationsfaktor für den Schlüsselbereich kms bei einer Installation mit drei Cassandra-Knoten 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, den Replikationsfaktor aber bei drei belassen, ist nicht gewährleistet, 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 erhöhte Latenz bei Datenschreibvorgängen.
Cassandra-Konsistenzebene
Die Cassandra-Konsistenzstufe ist definiert als die Mindestanzahl von Cassandra-Knoten, die einen Lese- oder Schreibvorgang bestätigen müssen, bevor der Vorgang als erfolgreich angesehen werden kann. Verschiedenen Edge-Schlüsselbereichen können unterschiedliche Konsistenzstufen zugewiesen werden.
Beim Herstellen einer Verbindung zu Cassandra für Lese- und Schreibvorgänge verwenden Message Processor- und Management Server-Knoten in der Regel den Cassandra-Wert LOCAL_QUORUM, um die Konsistenzebene für einen Schlüsselbereich anzugeben. Einige Schlüsselbereiche sind jedoch so definiert, dass sie eine Konsistenzstufe von eins verwenden.
Die Berechnung des Werts von LOCAL_QUORUM für ein Rechenzentrum lautet:
LOCAL_QUORUM = (replication_factor/2) + 1
Wie oben beschrieben, beträgt der Standard-Replikationsfaktor für eine Edge-Produktionsumgebung mit drei Cassandra-Knoten drei. Daher ist der Standardwert von LOCAL_QUORUM = (3/2) + 1 = 2 (der Wert wird auf eine Ganzzahl abgerundet).
Bei 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 kann der Cluster daher den Ausfall eines Knotens pro Rechenzentrum tolerieren.
Wenn Sie die Konsistenzstufe als LOCAL_QUORUM angeben, vermeidet Edge die Latenz, die durch die Validierung von Vorgängen über mehrere Rechenzentren hinweg erforderlich ist. Wenn ein Schlüsselbereich den Cassandra-Wert QUORUM als Konsistenzebene verwendet, müssen Lese-/Schreibvorgänge in allen Rechenzentren validiert werden.
So rufen Sie die Konsistenzebene auf, die von den Edge Message Processor- oder Management Server-Knoten verwendet wird:
- Melden Sie sich bei einem Message Processor-Knoten an.
- Wechseln Sie in das 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 beim Management Server-Knoten an.
- Wechseln Sie in das 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, hat dies keine Auswirkungen auf die Konsistenzstufe.