Konfiguration
Nehmen Sie als Beispiel eine einzelne Maschine mit mehreren Diensten (normalerweise mehrere Maschinen mit mehreren Diensten, aber ich habe nur einen Server)
Zunächst einmal ist jeder Redis-Client standardmäßig der Host, der sein kann über den Info-Replikationsbefehl angezeigt.
Jetzt müssen wir also drei Clients gleichzeitig öffnen, um einen Master und zwei Slaves zu simulieren, also müssen wir die Konfiguration ändern:
- Die Portnummer ändern
- Den PID-Namen ändern
- Das Protokoll ändern Name
- Ändern Sie den RDB-Namen
- Einstellungen Host-Verbindung (optional, verwenden Sie die Befehlszeile)
Kopieren Sie zunächst zwei Konfigurationsdateien als Slave-Konfiguration. Der Host kann die Standardeinstellung verwenden.
Nehmen Sie redis80.conf als Beispiel, um die oben genannten fünf Konfigurationspunkte nacheinander zu ändern. Für 81 werden nur die ersten vier Punkte geändert.
Dann starten Sie sie (79, 80, 81)
Setzen Sie Master und Slave:
- 80 ist in der Konfigurationsdatei (dauerhaft) OK eingestellt, direkt:
- 81 hat keine Konfiguration, Sie können es manuell in der Befehlszeile festlegen
Zu diesem Zeitpunkt 79 (Master) anzeigen:
Kopierprinzip
Vollständig kopieren
Alle Sobald der Slave eine Verbindung zum Master herstellt, werden alle Daten vom Host auf den Slave kopiert. Vollständige Kopie.
Inkrementelle Replikation
Nachdem der Slave mit dem Master verbunden ist, werden die später vom Master aktualisierten Daten nur für diesen Teil der Daten synchron auf dem Slave aktualisiert.
Test
- Der Slave ist standardmäßig schreibgeschützt und kopiert inkrementell die Daten des synchronisierten Masters:
- Der Host ist ausgefallen:
3. Aus der Ausfallsituation:
Verschachtelter Master-Slave
Wie in Abbildung 79 gezeigt, ist es der Host von 80, und 80 ist der Host von 81. Dies ist eine verschachtelte Master-Slave-Beziehung.
Sentinel-Modus
Die oben genannten 80 oberen und verschachtelten Master-Slaves werden alle von uns manuell über die Befehlszeile eingegeben. Der Zweck besteht darin, zu vermeiden der Host. Maschine Der Fensterzeitraum für Post-Write-Vorgänge erfordert einen manuellen Eingriff.
Sentinel wird unabhängig als unabhängiger Prozess ausgeführt. Das Prinzip besteht darin, dass Sentinel mehrere laufende Redis-Server überwacht, indem es Befehle sendet und auf die Antwort des Redis-Servers wartet. Wenn Sentinel erkennt, dass der Host offline ist, wählt es einen Slave-Computer aus, der als neuer Host „hochgefahren“ wird (automatische Fehlermigration). Wenn der ursprüngliche Host online geht, wird der ursprüngliche Host zum Slave des neuen Hosts. Das Prinzip besteht darin, andere Server über das Veröffentlichungs- und Abonnementmodell zu benachrichtigen, die Konfigurationsdatei zu ändern und dadurch den Host zu wechseln.
Was tun, wenn Sentinel ausfällt? Zur gegenseitigen Überwachung können mehrere Sentinels eingesetzt werden.
Bilder stammen von https://www.jianshu.com/p/06ab9daf921d.
- Subjectively Down (SDOWN) bezieht sich auf die Ausfallzeit einer einzelnen Sentinel-Instanz auf der Serverleitung Urteil.
Objective Down- (Objectively Down, als ODOWN bezeichnet) bezieht sich auf mehrere Sentinel-Instanzen, die subjektive Offline-Beurteilungen auf demselben Server vornehmen und über den Befehl SENTINEL is-master-down-by-addr miteinander kommunizieren. Das Ergebnis ist dass der Server offline ist.
Wenn der Host objektiv offline geht, stimmt Sentinel für einen neuen Host (
Der spezifische Algorithmus wird weggelassen), führt ein automatisches Failover (Failover) durch und benachrichtigt andere Server über Veröffentlichung und Abonnement, um den Host zu wechseln.
Konfigurieren Sie den SentinelZuerst gibt es eine detaillierte kommentierte Sentinel-Konfiguration im Installationsverzeichnis:
Erstellen Sie eine neue sentinel.conf, um 6379 zu überwachen, und der Rest kann standardmäßig eingestellt werden:
Starten Sie den Sentinel:
Test
Öffnen Sie verschiedene Portkonfigurationsdateien mehrere Sentinel-Clients und folgen dann demselben Muster ( faul
)