Cassandra zwei Knoten mit Redundanz

8

Ich habe zwei Server eingerichtet, auf denen Cassandra ausgeführt wird, indem Sie der Dokumentation auf der DataStax-Website folgen. Meine aktuelle Einstellung ist

  

1 Seed-Knoten (in beiden YAMLs konfiguriert)

Beim Ausführen sind beide Knoten aktiv (beim Testen über nodetool) und beide scheinen die Daten korrekt repliziert zu haben, aber ich habe bemerkt, dass der andere Knoten Clientverbindungen nicht zulässt, wenn ich den Startknoten herunterfahre über ihre API oder durch Verbindung mit Cqlsh) was ein Problem ist.

Meine Anforderung besteht darin, zwei Server zu haben, die perfekt aufeinander abgestimmt sind. Falls ein Server vorübergehend nicht verfügbar ist (z. B. aufgrund von Plattenspeicherausfällen), kann der andere Server die Anfragen übernehmen, bis der defekte Server wieder online ist .

Angesichts dieser Anforderung habe ich folgende Fragen:

  1. Muss ich beide Knoten als "Seed" -Knoten einrichten?
  2. Wie würde ich sicherstellen, dass alles auf beiden Servern repliziert wird? Passiert das automatisch oder gibt es irgendwo Einstellungen, die ich einstellen muss?

Vielen Dank im Voraus,

    
kha 05.01.2015, 11:32
quelle

1 Antwort

17

Cassandra macht keine Master-Slave-Replikation. In Cassandra gibt es keinen Meister. Stattdessen werden Daten über den Cluster verteilt. Der Verteilungsmechanismus hängt von einer Anzahl von Dingen ab.

Daten werden auf Knoten in Partitionen gespeichert. Denken Sie daran, Cassandra ist eine partitionierte Zeile speichern? Hier kommen Partitionen ins Spiel. Daten werden in Partitionen gespeichert. Alle Zeilen für eine Partition werden zusammen in einem einzelnen Knoten (und Replikaten) gespeichert. Wie viele Replikate hängen vom Replikationsfaktor der Tabelle ab. Wenn der Replikationsfaktor für eine Tabelle 3 ist, wird jede Partition für diese Tabelle (und damit alle Zeilen in dieser Partition) in zwei zusätzlichen Replikaten gespeichert. Es ist, als würde man sagen: "Ich möchte 3 Kopien dieser Daten".

Während des Schreibens können Clients eine Konsistenzstufe (CL) angeben. Dies ist die Anzahl der Knoten, die bestätigt werden müssen, damit ein Schreibvorgang erfolgreich ist. Clients können auch einen CL zum Lesen angeben. Cassandra gibt Leseanforderungen an n = CL-Knoten aus und nimmt den letzten Wert als Abfrageergebnis an.

Durch Abstimmung der Lese- und Schreib-CLs steuern Sie die Konsistenz. Wenn Lesen CL + Schreiben CL & gt; Replikationsfaktor (RF) erhalten Sie volle Konsistenz.

Im Hinblick auf die Fehlertoleranz können Sie CLs und RF optimieren, um das zu sein, was Sie brauchen. Wenn Sie beispielsweise RF = 3, Read CL = 2, Write CL = 2 haben, haben Sie volle Konsistenz und Sie können tolerieren, dass ein Knoten ausfällt. Für RF = 5, Lesen CL = 3, Schreiben CL = 3, haben Sie das gleiche, aber tolerieren können 2 Knoten gehen.

Ein Zwei-Knoten-Cluster ist nicht wirklich eine gute Idee. Sie können RF = 2 (alle replizierten Daten) setzen, CL = 2 schreiben und CL = 1 lesen. Dies bedeutet jedoch, dass bei einem ausgefallenen Knoten nur gelesen, aber nicht geschrieben werden kann. Sie können lesen CL = 2 und schreiben CL = 1, in diesem Fall, wenn ein Knoten ausfällt, können Sie schreiben, aber nicht lesen. Realistisch sollten Sie mindestens 5 (mindestens 4) Knoten mit einer RF = 3 wählen. Irgendwelche niedrigeren als das, und Sie bitten um Ärger.

    
ashic 05.01.2015, 12:21
quelle

Tags und Links