Zum Hauptinhalt springen

Cluster-Befehle

CLUSTER ADDSLOTS​

Syntax​

	CLUSTER ADDSLOTS slot [slot ...]

Dieser Befehl wird verwendet, um bestimmte Slots einem bestimmten Knoten zuzuweisen. Der Befehl empfangende Knoten führt die folgenden Prüfungen durch

  1. Ein Knoten weigert sich, den Besitz eines Slots zu übernehmen, der aus seiner Sicht bereits einem anderen Knoten zugewiesen ist.
  2. Der Befehl schlägt fehl, wenn ein Knoten mehrmals angegeben wird.
  3. Wenn der angegebene Slot-Wert außerhalb des vorgesehenen Bereichs (0-16383) liegt, gibt der Befehl einen Fehler außerhalb des Bereichs zurück.

Dieser Befehl wird anfänglich verwendet, um einen Redis-Cluster einzurichten oder einen defekten Cluster zu reparieren, bei dem Slot-Bereiche aufgrund von Ausfällen nicht zugewiesen sein könnten.

RESP-Antwort​

Gibt bei Erfolg +OK zurück, andernfalls --ERR Nachricht

CLUSTER ADDSLOTSRANGE​

Syntax​

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

Dieser Befehl ist ähnlich wie addslots und unterscheidet sich nur dadurch, dass er die Zuweisung von Slot-Bereichen an den empfangenden Knoten ermöglicht.

RESP-Antwort​

Gibt bei Erfolg +OK zurück, andernfalls --ERR Nachricht

CLUSTER BUMPEPOCH​

Syntax​

	CLUSTER BUMPEPOCH

Erhöht die Konfigurations-Epoch des empfangenden Knotens. Die Konfigurations-Epoch wird intern verwendet, um Konfigurationsänderungen im gesamten Cluster anzuwenden. Migrations- und Failover-Operationen erhöhen die Konfigurations-Epoch automatisch, wenn dies erforderlich ist. Sie sollte mit Vorsicht vom Cluster-Orchestrierer verwendet werden, um die Cluster-Konfiguration nach Bedarf anzupassen.

RESP-Antwort​

Gibt bei Erfolg +OK zurück, andernfalls --ERR Nachricht, falls vorhanden

CLUSTER BANLIST​

Syntax​

	CLUSTER BANLIST

Gibt die Liste der Knoten zurück, die derzeit von der Aufnahme in den Cluster ausgeschlossen sind, zusammen mit der Ablaufzeit in Sekunden. Dieser Befehl wird in Kombination mit CLUSTER FORGET verwendet, um zu überwachen, welche Knoten vom Hinzufügen zum Cluster ausgeschlossen sind.

RESP-Antwort​

Gibt eine Array-Liste von Strings "nodeid : expiry" oder ein leeres Array zurück.

127.0.0.1:7000> cluster banlist
1) "ad9e5b8bde5ffb0cf7a3372fe0345f765186983f : 57"

CLUSTER COUNTKEYSINSLOT​

Syntax​

	CLUSTER COUNTKEYSINSLOT slot

Gibt die Anzahl der vorhandenen Schlüssel zurück, die dem entsprechenden Slot zugeordnet sind. Der Befehl fragt nur die Daten des empfangenden Knotens ab. Für Slots, die nicht dem empfangenden Knoten gehören, ist das zurückgegebene Ergebnis immer Null.

RESP-Antwort​

Gibt einen Integer-Wert zurück.

CLUSTER DELKEYSINSLOT​

Syntax​

	CLUSTER DELKEYSINSLOT slot [slot ...]

Dieser Befehl fordert den empfangenden Knoten auf, alle Schlüssel zu löschen, die den angegebenen Knoten zugeordnet sind. Der Cluster-Betreiber kann diesen Befehl verwenden, um verwaiste Schlüssel zu bereinigen, die nicht mehr vom empfangenden Knoten bedient werden.

RESP-Antwort​

Gibt bei Erfolg +OK zurück, andernfalls --ERR Nachricht, falls vorhanden

CLUSTER DELKEYSINSLOTRANGE​

Syntax​

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

Dieser Befehl ist ähnlich wie delkeysinslot und unterscheidet sich nur dadurch, dass er die Angabe von Slot-Bereichen ermöglicht.

RESP-Antwort​

Gibt bei Erfolg +OK zurück, andernfalls --ERR Nachricht, falls vorhanden

CLUSTER DELSLOTS​

Syntax​

	CLUSTER DELSLOTS slot [slot ...]

Dieser Befehl fordert den empfangenden Knoten auf, zu vergessen, welcher Primärknoten die entsprechenden Slots bedient. Beachten Sie, dass dieser Befehl nur für den empfangenden Knoten funktioniert. Das Vergessen von Slots wird nicht an andere Knoten weitergegeben. Der empfangende Knoten wird das Akzeptieren von Gossip-Nachrichten nicht einstellen. In diesem Fall, wenn eine Gossip-Nachricht von einem entfernten Knoten empfangen wird, die die Zuweisung dieser Slots enthält, akzeptiert dieser Knoten die Zuweisung, wenn die Konfigurations-Epoch des Slot-Besitzers größer ist als die lokale Kopie.

RESP-Antwort​

Gibt bei Erfolg +OK zurück, andernfalls --ERR Nachricht, falls vorhanden

CLUSTER DELSLOTSRANGE​

Syntax​

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

Dieser Befehl ist ähnlich wie delslots und unterscheidet sich nur dadurch, dass er die Angabe von Slot-Bereichen ermöglicht, die am empfangenden Knoten vergessen werden sollen.

RESP-Antwort​

Gibt bei Erfolg +OK zurück, andernfalls --ERR Nachricht, falls vorhanden

CLUSTER ENDPOINT​

Syntax​

	CLUSTER ENDPOINT node-id

Dieser Befehl gibt den Endpunkt zurück, der mit der angegebenen Node-ID verknüpft ist. Wenn der empfangende Knoten keine Informationen über die angegebene Node-ID hat, gibt er "unassigned:0" zurück.

RESP-Antwort​

Bulk-String des Endpunkts "address:port" oder "unassigned:0"

CLUSTER FAILOVER​

Syntax​

	CLUSTER FAILOVER [FORCE | ABORT]

Dieser Befehl wird an ein Replikat gesendet, um einen manuellen Failover zu starten und die Rolle seines Primärknotens zu übernehmen. Er kann aufgerufen werden, um den aktuellen Primärknoten sicher gegen einen Replikatknoten auszutauschen, ohne Datenverlust, wenn der Primärknoten erreichbar ist. Wenn ein Replikat den obigen Befehl empfängt, führt es die folgenden Schritte aus

  1. Schreibt auf den Primärknoten stoppen. Das Verhalten kann mit der Option FORCE überschrieben werden.
  2. Der Primärknoten antwortet mit dem aktuellen Replikations-Offset, nachdem er alle Schreibvorgänge blockiert hat. Das Verhalten kann mit der Option FORCE überschrieben werden.
  3. Das Replikat wartet darauf, dass sein lokaler Replikations-Offset dem des Primärknotens entspricht. Das Verhalten kann mit der Option FORCE überschrieben werden.
  4. Das Replikat übernimmt die Rolle des neuen Primärknotens und erhöht seine lokale Konfigurations-Epoch.
  5. Der neue Primärknoten verbreitet die Konfigurationsänderung über Gossip.

Der Cluster-Betreiber kann auch die Option ABORT verwenden, um einen laufenden Failover gegebenenfalls abzubrechen.

RESP-Antwort​

Gibt bei Erfolg +OK zurück, andernfalls --ERR Nachricht, falls vorhanden. Dies bedeutet nicht, dass der FAILOVER erfolgreich war, sondern nur, dass die Hintergrundaufgabe für den Failover gestartet wurde.

CLUSTER FORGET​

Syntax​

	CLUSTER FORGET node-id [expiry-in-seconds]

Dieser Befehl wird verwendet, um einen Knoten aus der Perspektive des empfangenden Knotens zu vergessen. Da andere Knoten im Cluster den zu vergessenden Knoten kennen könnten, ist es möglich, dass der vergessene Knoten über Gossip wieder hinzugefügt wird. Aus diesem Grund ist jeder vergessene Knoten mit einem Ablaufdatum verbunden, das verhindert, dass dieser Knoten für den Ablaufzeitraum wieder hinzugefügt wird. Der Cluster-Betreiber kann eine benutzerdefinierte Ablaufperiode angeben. Der Standardwert ist 60 Sekunden. Um den Knoten im gesamten Cluster zu vergessen, muss der Betreiber den Befehl FORGET für jeden Knoten im Cluster einzeln ausgeben. Der Befehl schlägt fehl, wenn einer der folgenden Fälle eintritt

  1. Ein Knoten kann sich nicht selbst vergessen.
  2. Ein unbekannter Knoten kann nicht vergessen werden.
  3. Der empfangende Knoten ist ein Replikat und der zu vergessende Knoten ist sein Primärknoten.

RESP-Antwort​

Gibt bei Erfolg +OK zurück, andernfalls --ERR Nachricht, falls vorhanden.

CLUSTER GETKEYSINSLOT​

Syntax​

	CLUSTER GETKEYSINSLOT slot count

Dieser Befehl gibt ein Array von vorhandenen Schlüsseln zurück, die dem entsprechenden Slot zugeordnet sind. Er wird während der manuellen Neuverteilung zusammen mit anderen verwandten Befehlen (z. B. countkeysinslot) verwendet.

RESP-Antwort​

Ein Array von Schlüsseln oder leer.

CLUSTER INFO​

Syntax​

	CLUSTER INFO

CLUSTER INFO liefert Informationen im INFO-Stil über wichtige Parameter des Redis Clusters.

RESP-Antwort​

Bulk-String-Antwort: Eine Zuordnung zwischen benannten Feldern und Werten in Form von : Zeilen, getrennt durch Zeilenumbrüche, die aus den zwei Bytes CRLF bestehen.

CLUSTER KEYSLOT​

Syntax​

	CLUSTER KEYSLOT <key>

Der Befehl gibt einen Integer-Wert zurück, der den Slot identifiziert, zu dem der entsprechende Schlüssel gehasht wird.

RESP-Antwort​

Gibt einen Integer-Wert im Bereich von 0 bis 16383 zurück.

CLUSTER MEET​

Syntax​

	CLUSTER MEET address port

Dieser Befehl wird verwendet, um Garnet-Cluster-Instanzen miteinander zu verbinden. Standardmäßig vertrauen sich die Knoten nicht und akzeptieren nur Knoten, die über cluster meet oder über Gossip-Nachrichten von einem anderen vertrauenswürdigen Knoten eingeführt wurden. Der Cluster-Betreiber soll Knoten beim Einrichten des Clusters durch Ausgabe von "meet" verbinden. Wie oben angegeben, muss "meet" jedoch nicht gegenseitig erfolgen.

RESP-Antwort​

Gibt bei Erfolg +OK zurück, andernfalls --ERR Nachricht, falls vorhanden.

CLUSTER MYID​

Syntax​

	CLUSTER MYID

Dieser Befehl gibt die eindeutige Node-ID des empfangenden Knotens zurück.

RESP-Antwort​

Gibt einen Bulk-String der Node-ID zurück.

CLUSTER MYPARENTID​

Syntax​

	CLUSTER MYPARENTID

Dieser Befehl gibt die Node-ID seines übergeordneten Knotens (d. h. Primärknotens) zurück, wenn der Knoten ein Replikat ist.

RESP-Antwort​

Gibt einen Bulk-String des übergeordneten Knotens zurück, andernfalls seine eigene ID.

CLUSTER NODES​

Syntax​

	CLUSTER NODES

Dieser Befehl gibt die Cluster-Konfiguration aus der Perspektive des empfangenden Knotens zurück. Der Cluster-Betreiber sollte diesen Befehl verwenden, um Cluster-Informationen für Verwaltungsaufgaben, Debugging und Konfigurationsprüfungen abzurufen.

Die Ausgabe des Befehls ist ein durch Leerzeichen getrennter CSV-String, der Informationen über alle bekannten Knoten im Cluster enthält.

PS C:\Dev> redis-cli -p 7000
127.0.0.1:7000> cluster nodes
e39d271c7c4a4afca0e3d97154d2788502af12e3 192.168.1.26:7000@17000,test-host1 myself,master - 0 0 1 connected 0-5461
e0a69e89458c078d61a7a38f8e5f191522dcb1a7 192.168.1.26:7001@17001,test-host2 master - 0 0 2 connected 5462-10922
6fad21a7b28f1f2f05324257abf5e5e3b54e3286 192.168.1.26:7002@17002,test-host3 master - 0 0 3 connected 10923-16383
93a06cbed623ab044f809e2c67f3c3607ec0cc43 192.168.1.26:7003@17003,test-host4 slave e0a69e89458c078d61a7a38f8e5f191522dcb1a7 0 0 7 connected
03742a8ce43a911a81562e4947194bf54a8da2c6 192.168.1.26:7004@17004,test-host5 slave 6fad21a7b28f1f2f05324257abf5e5e3b54e3286 0 0 8 connected
e5f1c7ec263e5b9133d88535572901af881ab644 192.168.1.26:7005@17005,test-host6 slave e39d271c7c4a4afca0e3d97154d2788502af12e3 0 0 9 connected
127.0.0.1:7000>

Jede Zeile enthält die folgenden Felder

<id> <ip:port@cport[,hostname]> <flags> <master> <ping-sent> <pong-recv> <config-epoch> <link-state> <slot> <slot> ... <slot>

Um mit dem RESP-Protokoll kompatibel zu sein, geben wir die oben genannten Informationen aus, wenn wir auf den Befehl cluster nodes antworten. Nicht alle Informationen werden jedoch aktiv genutzt oder aktualisiert. Für jedes, das wir in Garnet aktiv nutzen, präsentieren wir unten eine kurze Beschreibung

  1. id: Die Node-ID, ein 40 Zeichen langer, global eindeutiger String, der für jeden Knoten beim Start generiert wird.
  2. ip:port@cport: Der Endpunkt des Knotens, mit dem Clients Abfragen verbinden sollen. Der zweite Port wird weder aktiv von den Garnet-Instanzen verwendet noch ist er für die Kommunikation geöffnet.
  3. hostname: Ein lesbarer String, der immer automatisch vom System bezogen wird. Er ist derzeit nicht konfigurierbar.
  4. flags: Komma-getrennte Flags myself,master,slave
  5. master: Wenn der Knoten ein Replikat ist und der Primärknoten bekannt ist, ist dies die Node-ID des Masters, andernfalls -
  6. ping-sent: N/A
  7. pong-recv: N/A
  8. config-epoch: Lokale Konfigurations-Epoch für den empfangenden Knoten.
  9. slot: Slots, die vom zugehörigen Knoten bedient werden. Wenn ein Knoten ein Replikat ist, bedient er implizit Lesevorgänge für diesen Slot.

Hinweis: Leider ist für diesen Befehl das Wort "slave" Teil des Protokolls und kann nicht entfernt werden, bis dieser Teil der API veraltet ist.

RESP-Antwort​

Gibt einen Bulk-String der serialisierten Cluster-Konfiguration zurück.

CLUSTER REPLICAS​

Syntax​

	CLUSTER REPLICAS node-id

Dieser Befehl gibt ein Array von Knoten zurück, die den durch die angegebene Node-ID repräsentierten Primärknoten replizieren. Die zurückgegebenen Informationen verwenden das gleiche Format wie in cluster nodes.

RESP-Antwort​

Array-Liste von Knoten, die den entsprechenden Knoten replizieren.

CLUSTER REPLICATE​

Syntax​

	CLUSTER REPLICATE node-id

Dieser Befehl konfiguriert den empfangenden Knoten so, dass er den durch die entsprechende Node-ID angegebenen Primärknoten repliziert. Sobald der Befehl erfolgreich ist, werden die übrigen Knoten über Gossip über die Konfigurationsänderung informiert.

Ein Knoten, der den obigen Befehl empfängt, wird ihn akzeptieren, vorausgesetzt, die folgenden Bedingungen sind erfüllt

  1. Der empfangende Knoten ist ein Primärknoten.
  2. Die angegebene Node-ID bezieht sich auf einen bekannten Primärknoten.
  3. Die angegebene Node-ID unterscheidet sich von der Node-ID des empfangenden Knotens.
  4. Der empfangende Knoten bedient keine Slots.

Nach Erhalt des Befehls versucht die Instanz sofort, sich an den Primärknoten anzuhängen und den neuesten Primär-Checkpoint abzurufen. Nach dessen Erhalt initiiert sie die AOF-Synchronisation vom Primärknoten und beginnt mit der Beantwortung von Leseanfragen. Die Anfrage zur Replikation wird asynchron ausgeführt, sodass die Antwort an den Client sofort erfolgt. Dies bedeutet nicht, dass das Replikat erfolgreich angehängt wurde, sondern nur, dass die Replikationsanfrage erfolgreich initiiert wurde.

RESP-Antwort​

Gibt bei Erfolg +OK zurück, andernfalls --ERR Nachricht, falls vorhanden.

CLUSTER SET-CONFIG-EPOCH​

Syntax​

	CLUSTER SET-CONFIG-EPOCH config-epoch

Dieser Befehl setzt eine spezifische Konfigurations-Epoch in einem neuen Knoten. Er ist nur erfolgreich, wenn

  1. Die Knotentabelle ist leer.
  2. Die Konfigurations-Epoch des empfangenden Knotens ist Null.

Dieser Befehl wird normalerweise beim Einrichten eines neuen Clusters aufgerufen.

RESP-Antwort​

Gibt bei Erfolg +OK zurück, andernfalls --ERR Nachricht, falls vorhanden.

CLUSTER SETSLOT​

Syntax​

	CLUSTER SETSLOT slot <IMPORTING source-node-id | MIGRATING target-node-id | NODE node-id | STABLE>

Dieser Befehl wird verwendet, um den Zustand eines Slots im empfangenden Knoten während der Migration zu ändern. Der Cluster-Betreiber kann diesen Befehl in Kombination mit MIGRATE, COUNTKEYSINSLOT und GETKEYSINSLOT verwenden, um den Slot-Besitz zwischen Knoten im Cluster zu übertragen.

Die folgenden Optionen sind verfügbar

MIGRATING​

Der Slot-Status wird auf MIGRATING gesetzt, wenn und nur wenn

  1. Der empfangende Knoten der primäre Besitzer des Slots ist.
  2. Der Slot sich nicht bereits im Migrationsstatus befindet.
  3. Die angegebene Node-ID bekannt ist und einem Primärknoten entspricht.

Aufgrund der oben genannten Bedingungen können Slots nur am Quellknoten in den Status MIGRATING übergehen. Daher werden Abfragen zu Schlüsseln, die einem Slot mit dem Status MIGRATING zugeordnet sind, am Quellknoten wie folgt verarbeitet

  • Leseanfragen werden wie gewohnt verarbeitet, wenn der Schlüssel existiert, andernfalls werden sie mit einer -MOVED-Antwort an den Zielknoten weitergeleitet.
  • Schreibanfragen für vorhandene Schlüssel werden mit einer -MIGRATING-Antwort abgelehnt, andernfalls werden sie mit einer -ASK-Antwort an den Zielknoten weitergeleitet.

HINWEIS: Diese Statusänderung ist transient und wird daher nicht über Gossip an die restlichen Cluster-Knoten weitergegeben. Die -MOVED-Umleitung wird jedoch weiterhin ausgegeben und zeigt auf den Quellknoten des Slots.

IMPORTING​

Der Slot-Status wird auf IMPORTING gesetzt, wenn und nur wenn

  1. Der empfangende Knoten ein Primärknoten ist, der den Slot noch nicht besitzt.
  2. Die entsprechende Source-Node-ID ein bekannter Primärknoten ist, der den Slot besitzt.

Alle Anfragen, die sich auf Schlüssel beziehen, die dem importierenden Slot zugeordnet sind, werden nur verarbeitet, wenn sie mit ASKING eingeleitet werden, andernfalls geben alle Anfragen eine -MOVED-Antwort aus.

HINWEIS: Diese Statusänderung ist transient und wird daher nicht über Gossip an die restlichen Cluster-Knoten weitergegeben. Die -MOVED-Umleitung wird jedoch weiterhin ausgegeben und zeigt auf den Quellknoten des Slots.

STABLE​

Diese Option wird verwendet, um den Zustand MIGRATING oder IMPORTING zu löschen. Sie wird hauptsächlich verwendet, um Cluster zu reparieren, die aufgrund möglicher Ausfälle in einem schlechten Zustand feststecken.

NODE​

Diese Option wird verwendet, um den Besitz des migrierenden Slots an den Zielknoten zu übertragen.

Wenn der Knoten, der den Befehl empfängt, sich im Importierungszustand befindet (d. h. der Zielknoten), setzt er sich selbst als Besitzer des Knotens und erhöht die Konfigurations-Epoch. Wenn der Knoten, der den Befehl empfängt, sich im Migrationszustand befindet (d. h. der Quellknoten), weist er dem Zielknoten den Besitz des Knotens zu, erhöht jedoch nicht die Epoch.

HINWEIS Weitere Informationen zum Befehl finden Sie auf der Seite zur Schlüsselmigration.

RESP-Antwort​

Gibt bei Erfolg +OK zurück, andernfalls --ERR Nachricht, falls vorhanden.

CLUSTER SETSLOTRANGE​

Syntax​

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

Dieser Befehl ist ähnlich wie setslot und unterscheidet sich nur dadurch, dass er die Angabe von Slot-Bereichen ermöglicht.

RESP-Antwort​

Gibt bei Erfolg +OK zurück, andernfalls --ERR Nachricht, falls vorhanden.

CLUSTER SHARDS​

Syntax​

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

Dieser Befehl gibt Details über die Shards im Cluster zurück. Shards haben einen einzigen Primärknoten und mehrere Replikate, die einen bestimmten Bereich von Slots bedienen. Die zurückgegebenen Informationen werden aus der lokalen Konfigurationsansicht des empfangenden Knotens generiert.

Ein Beispiel für die Befehlsausgabe ist unten dargestellt.

PS C:\Dev> redis-cli -p 7001
127.0.0.1:7001> cluster shards
1) 1) "slots"
   2) 1) (integer) 5462
      2) (integer) 10922
   3) "nodes"
   4) 1)  1) "id"
          2) "e0f69d9f8d4d2b2fa100d1dd1fbd7bc2cf4e9396"
          3) "port"
          4) (integer) 7001
          5) "address"
          6) "10.159.2.73"
          7) "role"
          8) "PRIMARY"
          9) "replication-offset"
         10) (integer) 64
         11) "health"
         12) "online"
      2)  1) "id"
          2) "4e79261982fe0162262da2f912f6dd4bc9161099"
          3) "port"
          4) (integer) 7003
          5) "address"
          6) "10.159.2.73"
          7) "role"
          8) "REPLICA"
          9) "replication-offset"
         10) (integer) 0
         11) "health"
         12) "online"
2) 1) "slots"
   2) 1) (integer) 0
      2) (integer) 5461
   3) "nodes"
   4) 1)  1) "id"
          2) "228133c63d1151f784c9404241c8b06afbc83117"
          3) "port"
          4) (integer) 7000
          5) "address"
          6) "10.159.2.73"
          7) "role"
          8) "PRIMARY"
          9) "replication-offset"
         10) (integer) 0
         11) "health"
         12) "online"
      2)  1) "id"
          2) "96cd8f6d4b57cea02deb9147cdcfac79a4641d0c"
          3) "port"
          4) (integer) 7005
          5) "address"
          6) "10.159.2.73"
          7) "role"
          8) "REPLICA"
          9) "replication-offset"
         10) (integer) 0
         11) "health"
         12) "online"
3) 1) "slots"
   2) 1) (integer) 10923
      2) (integer) 16383
   3) "nodes"
   4) 1)  1) "id"
          2) "810544afb338b6b217a6e169b0115d70337bf557"
          3) "port"
          4) (integer) 7002
          5) "address"
          6) "10.159.2.73"
          7) "role"
          8) "PRIMARY"
          9) "replication-offset"
         10) (integer) 0
         11) "health"
         12) "online"
      2)  1) "id"
          2) "2035250845f809ab23a2f4c51e73b1c4541c0092"
          3) "port"
          4) (integer) 7004
          5) "address"
          6) "10.159.2.73"
          7) "role"
          8) "REPLICA"
          9) "replication-offset"
         10) (integer) 0
         11) "health"
         12) "online"

RESP-Antwort​

Array-Antwort: eine verschachtelte Liste von Hash-Bereichen und Knoteninformationen, gruppiert nach Shard.

CLUSTER SLOTS​

Syntax​

	CLUSTER SLOTS

CLUSTER SLOTS gibt Details darüber zurück, welche Cluster-Slots welchen Redis-Instanzen zugeordnet sind.

RESP-Antwort​

Array-Antwort: verschachtelte Liste von Slot-Bereichen mit Netzwerkinformationen.

ASKING​

Syntax​

	ASKING

Wenn ein Cluster-Client eine -ASK-Umleitung erhält, wird der Befehl ASKING an den Zielknoten gesendet, gefolgt von dem Befehl, der umgeleitet wurde. Dies geschieht normalerweise automatisch durch Cluster-Clients.

RESP-Antwort​

Einfache Zeichenketten-Antwort: OK.

READONLY​

Syntax​

	READONLY

Aktiviert Leseabfragen für eine Verbindung zu einem Redis Cluster Replikatknoten.

RESP-Antwort​

Einfache Zeichenketten-Antwort: OK.

READWRITE​

Syntax​

	READWRITE

Deaktiviert Leseabfragen für eine Verbindung zu einem Redis Cluster Replikatknoten.

RESP-Antwort​

Einfache Zeichenketten-Antwort: OK.

RESET​

Syntax​

	RESET

Dieser Befehl führt ein vollständiges Zurücksetzen des serverseitigen Kontexts der Verbindung durch, was den Effekt eines Trennens und erneuten Verbindens nachahmt.

RESP-Antwort​

Einfache String-Antwort: RESET.