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 sich Replikate befinden platziert.

Die Gesamtzahl der Replikate für einen Schlüsselraum in einem Cassandra-Cluster wird als den Replikationsfaktor von keyspace. Ein Replikationsfaktor von 1 bedeutet, dass es nur einen Kopie jeder Zeile im Cassandra-Cluster. Ein Replikationsfaktor von zwei bedeutet, dass es zwei Kopien jeder Zeile, wobei sich jede Kopie auf einem anderen Knoten befindet. Alle Replikate sind gleich wichtig: gibt es keine primäre oder Master-Replikation.

In einem Produktionssystem mit drei oder mehr Cassandra-Knoten in jedem Rechenzentrum wird die Standardeinstellung Replikationsfaktor für einen Edge-Schlüsselraum ist 3. In der Regel ist der Replikationsfaktor sollte die Anzahl der Cassandra-Knoten im Cluster nicht überschreiten.

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 dazu diesen 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 sollte in etwa so aussehen, 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 ein beabsichtigtes Systemverhalten.

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

Cassandra-Konsistenzebene

Das Cassandra-Konsistenzniveau ist definiert als die Mindestanzahl von Cassandra-Knoten, die einen Lese- oder Schreibvorgang bestätigen, bevor der Vorgang als erfolgreich betrachtet werden kann. Verschiedenen Konsistenzebenen können verschiedenen Edge-Schlüsselbereichen zugewiesen werden.

Beim Herstellen einer Verbindung zu Cassandra für Lese- und Schreibvorgänge, Message Processor und Management Serverknoten verwenden in der Regel den Cassandra-Wert LOCAL_QUORUM, um gibt die Konsistenzebene für einen Schlüsselraum an. Einige Schlüsselbereiche sind jedoch so definiert, dass ein Konsistenzstufe 1.

Der Wert von LOCAL_QUORUM für ein Rechenzentrum wird so berechnet:

LOCAL_QUORUM = (replication_factor/2) + 1

Wie oben beschrieben, kann der Standard-Replikationsfaktor für eine Edge-Produktionsumgebung mit drei Cassandra-Knoten sind drei. Dementsprechend ist der Standardwert LOCAL_QUORUM = (3/2) +1 = 2 (der Wert wird auf eine Ganzzahl abgerundet).

Wenn LOCAL_QUORUM = 2, sind mindestens zwei der drei Cassandra-Knoten in den Daten um erfolgreich zu sein, muss das Center auf einen Lese-/Schreibvorgang reagieren. Für drei Knoten Cassandra-Cluster konnte der Cluster daher tolerieren, dass ein Knoten pro Rechenzentrum ausgefallen ist.

Durch Angabe der Konsistenzebene als LOCAL_QUORUM vermeidet Edge die Latenz die für die Validierung von Abläufen in mehreren Rechenzentren erforderlich sind. Wenn ein Schlüsselraum die Cassandra- QUORUM als Konsistenzebene haben, müssen Lese-/Schreibvorgänge in allen Rechenzentren validiert.

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 in das 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 in das 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.