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
-pcasspass
] -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.