blob: 1924158e51a8b30a6abbc5a0429ee23add9d36fc (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
In Redis Cluster, each node keeps track of which master is serving a particular
hash slot.
The `DELSLOTS` command asks a particular Redis Cluster node to forget which
master is serving the hash slots specified as arguments.
In the context of a node that has received a `DELSLOTS` command and has
consequently removed the associations for the passed hash slots, we say those
hash slots are _unbound_. Note that the existence of unbound hash slots occurs
naturally when a node has not been configured to handle them (something that can
be done with the `ADDSLOTS` command) and if it has not received any information
about who owns those hash slots (something that it can learn from heartbeat or
update messages).
If a node with unbound hash slots receives a heartbeat packet from another node
that claims to be the owner of some of those hash slots, the association is
established instantly. Moreover, if a heartbeat or update message is received
with a configuration epoch greater than the node's own, the association is
re-established.
However, note that:
1. The command only works if all the specified slots are already associated with
some node.
2. The command fails if the same slot is specified multiple times.
3. As a side effect of the command execution, the node may go into _down_ state
because not all hash slots are covered.
## Example
The following command removes the association for slots 5000 and 5001 from the
node receiving the command:
> CLUSTER DELSLOTS 5000 5001
OK
## Usage in Redis Cluster
This command only works in cluster mode and may be useful for debugging and in
order to manually orchestrate a cluster configuration when a new cluster is
created. It is currently not used by `redis-trib`, and mainly exists for API
completeness.
@return
@simple-string-reply: `OK` if the command was successful. Otherwise an error is
returned.
|
