Diese Seite wurde von der Cloud Translation API übersetzt.

Informationen zum Cassandra-Replikationsfaktor und zur Konsistenzstufe

Informationen zum Cassandra-Replikationsfaktor

Cassandra speichert Datenreplikate auf mehreren Knoten, um Zuverlässigkeit und Fehlertoleranz zu gewährleisten. Die Replikationsstrategie für jeden Edge-Schlüsselraum bestimmt die Knoten, auf denen Replikate platziert werden.

Die Gesamtzahl der Replikate für einen Schlüsselraum in einem Cassandra-Cluster wird als Replikationsfaktor des Schlüsselraums bezeichnet. Ein Replikationsfaktor von 1 bedeutet, dass nur eine Kopie jeder Zeile im Cassandra-Cluster 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 weder eine primäre noch ein Master-Replikat.

In einem Produktionssystem mit drei oder mehr Cassandra-Knoten in jedem Rechenzentrum ist der Standardreplikationsfaktor für einen Edge-Schlüsselraum 3. Als allgemeine Regel gilt, dass der Replikationsfaktor die Anzahl der Cassandra-Knoten im Cluster nicht überschreiten darf.

Mit dem folgenden Verfahren können Sie das Cassandra-Schema anzeigen, das den Replikationsfaktor für jeden Edge-Schlüsselraum anzeigt:

Melden Sie sich bei einem Cassandra-Knoten an.
Führen Sie den folgenden Befehl aus:
```
/opt/apigee/apigee-cassandra/bin/cqlsh $(hostname -i) [-u cassuser -p casspass] -e "select keyspace_name, replication from system_schema.keyspaces;"
```
Dabei wird $(hostname -i) der IP-Adresse des Cassandra-Knotens zugeordnet. Alternativ können Sie $(hostname -i) durch die IP-Adresse des Knotens ersetzen.

cassuser: Wenn Sie die Cassandra-Authentifizierung aktiviert haben, übergeben Sie den Cassandra-Nutzernamen. Dies ist optional und kann übersprungen werden, wenn Sie die Cassandra-Authentifizierung nicht aktiviert haben.

casspass: Wenn Sie die Cassandra-Authentifizierung aktiviert haben, übergeben Sie das Cassandra-Passwort. Dies ist optional und kann übersprungen werden, wenn Sie die Cassandra-Authentifizierung nicht aktiviert haben.

Die Ausgabe sieht in etwa so aus, wobei jede Zeile einen Schlüsselraum darstellt:

  keyspace_name       | replication                                                                 
  kms                 | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
  system_distributed  | {'class': 'org.apache.cassandra.locator.SimpleStrategy', 'replication_factor': '3'}
  apprepo             | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}

Sie sehen, dass für Rechenzentrum 1, dc-1 der Standard-Replikationsfaktor für den kms-Schlüsselraum bei einer Installation mit drei Cassandra-Knoten drei beträgt. Bei bestimmten Cassandra-internen Schlüsselbereichen wie system, system_schema usw. können die Replikationsstrategie und der Replikationsfaktor unterschiedlich sein. Das ist beabsichtigtes Systemverhalten.

Wenn Sie dem Cluster zusätzliche Cassandra-Knoten hinzufügen, ist der Standardreplikationsfaktor nicht betroffen.

Cassandra-Konsistenzebene

Das Cassandra-Konsistenzniveau 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. Verschiedenen Konsistenzebenen können verschiedenen Edge-Schlüsselbereichen zugewiesen werden.

Wenn Sie für Lese- und Schreibvorgänge eine Verbindung zu Cassandra herstellen, verwenden die Knoten des Message Processor und des Management Servers normalerweise den Cassandra-Wert LOCAL_QUORUM, um die Konsistenzebene für einen Schlüsselbereich anzugeben. Einige Schlüsselbereiche sind jedoch so definiert, dass die Konsistenzebene 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 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 antworten, 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 Konsistenzebene als LOCAL_QUORUM vermeidet Edge die Latenz, die bei der Validierung von Vorgängen in mehreren Rechenzentren erforderlich ist. Wenn ein Schlüsselraum den Cassandra-Wert QUORUM als Konsistenzebene verwendet, müssen Lese-/Schreibvorgänge in allen Rechenzentren validiert werden.

So zeigen Sie die Konsistenzebene an, 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 Konsistenz von Lese- und Schreibvorgängen:
```
grep -ri "consistency.level" *
```
Melden Sie sich beim Knoten des Verwaltungsservers an.
Wechseln Sie zum Verzeichnis /opt/apigee/edge-management-server/conf:
```
cd /opt/apigee/edge-management-server/conf
```
Wiederholen Sie Schritt 3.

Wenn Sie dem Cluster weitere Cassandra-Knoten hinzufügen, hat dies keine Auswirkungen auf die Konsistenzebene.