Professional Documents
Culture Documents
hash slot, but only if the key in question exists, otherwise the query is forwarded using
a -ASK redirection to the node that is target of the migration.
• When a slot is set as IMPORTING, the node will accept all queries that are about this
hash slot, but only if the request is preceded by an ASKING command. If
the ASKING command was not given by the client, the query is redirected to the real
hash slot owner via a -MOVED redirection error, as would happen normally.
Let's make this clearer with an example of hash slot migration. Assume that we have
two Redis master nodes, called A and B. We want to move hash slot 8 from A to B, so
we issue commands like this:
All the other nodes will continue to point clients to node "A" every time they are queried
with a key that belongs to hash slot 8, so what happens is that:
This way we no longer create new keys in "A". In the meantime, a special program
called redis-trib used during reshardings and Redis Cluster configuration will migrate
existing keys in hash slot 8 from A to B. This is performed using the following command:
The above command will return count keys in the specified hash slot. For every key
returned, redis-trib sends node "A" a MIGRATE command, that will migrate the
specified key from A to B in an atomic way (both instances are locked for the time
(usually very small time) needed to migrate a key so there are no race conditions). This
is how MIGRATE works:
MIGRATE will connect to the target instance, send a serialized version of the key, and
once an OK code is received, the old key from its own dataset will be deleted. From the
point of view of an external client a key exists either in A or B at any given time.