Redis: Nur-Lese-Slave vs. Failover-Slave?

Ich lese eine Menge Dokumentation zu Redis-Netzwerkkonfigurationen und bin verwirrt darüber, wie es scheint, dass die Anforderungen in meinem Architektur-Mental-Modell nicht mit den aktuellen Optionen übereinstimmen.

Erstens: Ich brauche keine Scherben, weil die Skalierbarkeit im Moment kein Thema ist. Also erstmal ein Master (Knoten M).

Zweitens: Ich möchte Redundanz, dh, wenn ein Master-Knoten ausfällt, möchte ich, dass ein zweiter Knoten die Anforderungen übernimmt, die der Client an ihn sendet. Nennen wir dies den ersten Slave: den Failover-Slave (Knoten FS).

Drittens: Ich möchte auch einen anderen Replikatknoten, nämlich einen Slave, der jedoch nur schreibgeschützte Abfragen bedient. Wenn ein Client eine Verbindung zu ihm herstellt und der Client versucht, Daten zu ändern, sollte der Knoten einen Fehler melden. Nennen wir dies den zweiten Slave: den Nur-Lese-Slave (RS).

Zuletzt: Ich möchte ein Failover für den Nur-Lese-Slave. Das heißt, für den Fall, dass RS stirbt, möchte ich, dass ein anderer Nur-Lese-Slave seine Aufgaben übernimmt. Nennen wir dies den vierten Slave: den schreibgeschützten Failover-Slave (FRS).

Gibt es eine Möglichkeit, Redis so zu konfigurieren? Scheint, dass alle Bereitstellungsmodi (hat diesen Artikel gelesen: https://blog.octo.com/en/what-redis-deployment-do-you-need/ ) einen einzigen Master außer dem Cluster haben. Es sieht so aus, als wäre mein "FS" -Knoten ein zweiter Master, da er Schreibanfragen akzeptiert. Die Clusterkonfiguration ist jedoch standardmäßig auf "Sharding" aktiviert und es scheint, als gäbe es keine normale Möglichkeit, ihn zu deaktivieren, es sei denn, ich vermisse etwas.

Soweit ich weiß, wird redis sentinel Ihren Anforderungen gerecht.

Sie haben 1 Master (M) und 3 Slaves (FS, RS und FRS). Jeder der Slaves ist mit demselben Master verbunden.

Anschließend stellen Sie eine ungerade Anzahl von Sentinel-Prozessen bereit, die den Master überwachen. Wenn der Master ausfällt, befördern die Sentinels einen der drei Slaves zum neuen Master.

Nun möchten Sie aus Ihren Notizen den "FS" -Slave zum neuen Master machen. Sentinel weiß nicht, dass "FS" etwas Besonderes ist. Er kann jeden der drei Slaves als Kandidaten für den neuen Master auswählen. Um "FS" speziell zu machen, müssen Sie für jeden der Slaves "Replikat-Priorität" einstellen. Sie möchten nicht, dass "RS" und "FRS" jemals Master werden. Setzen Sie daher die Replikatpriorität für beide Knoten auf 0. Dann wird Sentinel nur dann "FS" berücksichtigen, wenn es Zeit für ein Failover ist.

Der andere Teil Ihrer Frage - was passiert, wenn "RS" stirbt? Es gibt keinen Failover-Mechanismus für Slaves - er wird einfach nicht benötigt. "RS" und "FRS" sind nur zwei Lesereplikate, die beide auf denselben Master verweisen. Clients sollten so konfiguriert sein, dass sie eine der beiden Repliken nach dem Zufallsprinzip testen - damit Sie die Last verteilen. Wenn "RS" stirbt, versucht der Client einfach "FRS". Da dies schreibgeschützt ist, spielt die Datenkonsistenz keine Rolle.

Für RS und FRS - legen Sie eine zusätzliche Eigenschaft fest replica-read-only yes. Dadurch wird sichergestellt, dass das Schreiben fehlschlägt.

Sie können auch eine Nicht-Sentinel-Konfiguration verwenden. In diesem Fall wird das Failover von M auf FS nicht automatisch durchgeführt. Wenn / Wenn der Master M ausfällt, müssen Sie a) ihn erkennen, b) FS als Slave von keinem markieren, c) sicherstellen, dass alle Ihre Redis-Clients mit dem Schreiben auf den neuen Master beginnen, und d) RS und FRS neu konfigurieren, um mit dem Folgen zu beginnen der neue meister. Sentinel macht das automatisch, hat aber die Komplexität erhöht. Sie können es auch ganz einfach von Hand machen.