Zum Hauptinhalt springen

Resharding-Übersicht

Der Granat-Cluster unterstützt Hoch- und Herunterskalierungsoperationen zur Abmilderung von Nachfrageschwankungen oder für Failover. Der Cluster-Betreiber kann Knoten hinzufügen/entfernen und Online-Resharding ohne Ausfallzeit durchführen (d. h. Clients können weiterhin Abfragen ausführen, während die zugehörigen Daten zwischen den Knoten migriert werden). Im Hintergrund wird das Resharding durch die Verwendung einer Kombination von CLUSTER SETSLOT- und MIGRATE-Befehlen erreicht. Diese Seite bietet einen Überblick über die von diesen Befehlen unterstützten Optionen und Funktionen sowie einige Beispiele für deren Verwendung zum Resharding von Slots auf verfügbaren Primärknoten. Weitere Details zu den hier genannten Befehlen finden Sie in der Dokumentation zu den Cluster-Befehlen.

Slot-Migration-Übersicht

Die Migration eines Slots von einem (Quell-)Primärknoten zu einem anderen (Ziel-)Primärknoten umfasst die folgenden Schritte:

  1. Ändern Sie den Slot-Status am Zielknoten in den Status IMPORTING.
  2. Ändern Sie den Slot-Status am Quellknoten in den Status MIGRATING.
  3. Migrieren Sie die tatsächlichen Schlüssel vom Quell- zum Zielknoten.
  4. Informieren Sie die Ziel- und Quellknoten über die Besitzänderung, indem Sie den Slot-Besitzer und den Status ändern.

Der Cluster-Betreiber kann die obigen Schritte entweder manuell mithilfe einer Kombination von CLUSTER SETSLOT-, MIGRATE-, CLUSTER COUNTKEYSINSLOT- und CLUSTER GETKEYSINSLOT-Befehlen ausführen oder eine Variante des MIGRATE-Befehls verwenden, um alle Schritte des Prozesses automatisch auszuführen.

Manuelle Slot-Migration​

Der erste Schritt bei der Migration eines Slots zwischen zwei Knoten besteht darin, den Slot entsprechend auf IMPORTING und MIGRATING zu setzen. Dies wird mit einem der folgenden Befehle erreicht:

CLUSTER SETSLOT <slot> <IMPORTING node-id | MIGRATING node-id | NODE node-id | STABLE>
CLUSTER SETSLOTRANGE <IMPORTING node-id | MIGRATING node-id | NODE node-id | STABLE> start-slot end-slot [start-slot end-slot ...]

Das Ändern des Slot-Status verhindert, dass Clients Schreibvorgänge am Quellknoten ausführen, bis die Migration abgeschlossen ist. Dies gewährleistet die Schreibsicherheit, blockiert jedoch nicht das Lesen vorhandener Schlüssel. Der Quellknoten leitet Lesevorgänge für nicht vorhandene Schlüssel und Schreibvorgänge an den Zielknoten weiter. Clients können vor jeder Schreiboperation den Befehl ASKING verwenden, um Schreibbeschränkungen zu überschreiben. Dies sollte jedoch mit Vorsicht verwendet werden, da keine Schutzmaßnahmen implementiert sind, um den Verlust von Schreibvorgängen während der Migration zu verhindern.

Der nächste Schritt nach der Änderung des Status des zu migrierenden Slots besteht darin, alle Schlüssel zu finden, die auf den entsprechenden Migrationsslot abgebildet werden, und sie an den Zielknoten zu übertragen. Dies wird mit den folgenden Befehlen erreicht:

CLUSTER COUNTKEYSINSLOT slot
CLUSTER GETKEYSINSLOT slot
migrate <host> <port> [KEY] | [destination-db] [COPY] [REPLACE] [AUTH password] [AUTH2 username password] [KEYS keys]

Der Betreiber kann die obigen Befehle verwenden, um vorhandene Schlüssel zu durchlaufen und sie an den Zielknoten zu übertragen. Wenn die Datenmigration abgeschlossen ist, sollte der Betreiber CLUSTER SETSLOT NODE <node-id> an den Quell- und Zielknoten ausgeben, um die Änderung des Slot-Besitzers abzuschließen. Wenn die Migration fehlschlägt, ist der Cluster-Betreiber dafür verantwortlich, mögliche Fehler zu beheben, um den Cluster in einen stabilen Zustand zu bringen. Dies kann durch die Verwendung einer Kombination der folgenden Befehle nach Bedarf erfolgen:

CLUSTER SETSLOT STABLE

CLUSTER DELKEYSINSLOT <slot>

CLUSTER DELKEYSINSLOTRANGE start-slot end-slot [start-slot end-slot ...].

Automatische Slot-Migration​

Die manuelle Migration von Schlüsseln ist eine umständliche und fehleranfällige Operation. Der Cluster-Betreiber kann dies überwinden, indem er eine Variante des MIGRATE-Befehls verwendet, die ganze Slots oder Slot-Bereiche auf einmal migriert.

migrate <host> <port> [KEY] | [destination-db] [COPY] [REPLACE] [AUTH password] [AUTH2 username password] [[SLOTS slot] [SLOTSRANGE start-slot end-slot [start-slot end-slot ...]]

Die Slot-Variante des MIGRATE-Befehls führt alle oben genannten Operationen automatisch durch. Sie startet einen Hintergrundprozess, der alle notwendigen Operationen ausführt. Der Cluster-Betreiber kann den Fortschritt der Migration mit den folgenden Befehlen überwachen:

CLUSTER MTASKS
CLUSTER SLOTSTATE <slot>

Beispiel für die Migration von Slots

Dieser Abschnitt zeigt ein Beispiel für die Verwendung der Option „Migrate Slots“, um mehrere Slots auf einmal zu migrieren. Dieses Beispiel geht von einer bestehenden Cluster-Bereitstellung mit 2 Knoten aus, wie unten gezeigt:

127.0.0.1:7000> cluster nodes
7e59ecfef6cae5e22b47d8f63c789a1e66031a60 192.168.1.26:7000@17000,test-host1 myself,master - 0 0 1 connected 0-8191
4cb7e9cb54684d20f777c2916145acfd6be48efe 192.168.1.26:7001@17001,test-host2 master - 0 0 2 connected 8192-16383

Nachdem Daten zu Knoten 2 hinzugefügt wurden, können wir identifizieren, welche Slots die entsprechenden Schlüssel enthalten. Für diesen Testfall werden wir nur die zugehörigen Slots zu Knoten 1 verschieben. Alternativ können wir ganze Slot-Bereiche oder einzelne Schlüssel manuell verschieben.

PS C:\Dev> redis-cli -p 7001
127.0.0.1:7001> set x 12
OK
127.0.0.1:7001> set y 22
OK
127.0.0.1:7001> set a 33
OK
127.0.0.1:7001> set d 44
OK
127.0.0.1:7001> get x
"12"
127.0.0.1:7001> get y
"22"
127.0.0.1:7001> get a
"33"
127.0.0.1:7001> get d
"44"
127.0.0.1:7001> cluster nodes
4cb7e9cb54684d20f777c2916145acfd6be48efe 192.168.1.26:7001@17001,test-host2 myself,master - 0 0 2 connected 8192-16383
7e59ecfef6cae5e22b47d8f63c789a1e66031a60 192.168.1.26:7000@17000,test-host1 master - 0 0 1 connected 0-8191
127.0.0.1:7001> cluster keyslot x
(integer) 16287
127.0.0.1:7001> cluster keyslot y
(integer) 12222
127.0.0.1:7001> cluster keyslot a
(integer) 15495
127.0.0.1:7001> cluster keyslot d
(integer) 11298

Um einzelne Slots zu verschieben, verwenden wir die Option SLOTS wie unten gezeigt:

127.0.0.1:7001> migrate 192.168.1.26 7000 "" 0 -1 SLOTS 16287 12222 15495 11298
OK
127.0.0.1:7001> cluster nodes
4cb7e9cb54684d20f777c2916145acfd6be48efe 192.168.1.26:7001@17001,test-host2 myself,master - 0 0 2 connected 8192-11297 11299-12221 12223-15494 15496-16286 16288-16383
7e59ecfef6cae5e22b47d8f63c789a1e66031a60 192.168.1.26:7000@17000,test-host1 master - 0 0 3 connected 0-8191 11298 12222 15495 16287

Nach Abschluss der Migration können wir die aktualisierte Konfiguration anzeigen, indem wir cluster nodes auf jedem Knoten aufrufen. Zu diesem Zeitpunkt erhalten wir, wenn wir eine Leseanfrage an Knoten 2 senden, eine Umleitungsnachricht an Knoten 1. Um auf die migrierten Schlüssel zuzugreifen, müssen wir uns mit Knoten 1 verbinden, da dieser der Besitzer der Slots ist, die mit den entsprechenden Schlüsseln verbunden sind.

127.0.0.1:7001> get x
(error) MOVED 16287 192.168.1.26:7000
127.0.0.1:7001> get y
(error) MOVED 12222 192.168.1.26:7000
127.0.0.1:7001> get a
(error) MOVED 15495 192.168.1.26:7000
127.0.0.1:7001> get d
(error) MOVED 11298 192.168.1.26:7000
127.0.0.1:7001> exit
PS C:\Dev> redis-cli -p 7000
127.0.0.1:7000> get x
"12"
127.0.0.1:7000> get y
"22"
127.0.0.1:7000> get a
"33"
127.0.0.1:7000> get d
"44"
127.0.0.1:7000> cluster nodes
7e59ecfef6cae5e22b47d8f63c789a1e66031a60 192.168.1.26:7000@17000,test-host1 myself,master - 0 0 3 connected 0-8191 11298 12222 15495 16287
4cb7e9cb54684d20f777c2916145acfd6be48efe 192.168.1.26:7001@17001,test-host2 master - 0 0 2 connected 8192-11297 11299-12221 12223-15494 15496-16286 16288-16383
127.0.0.1:7000>