Now that we have the Redis Cluster object instance stored in the rc variable we are ready to use the object like if it was a normal Redis object instance.
This is exactly what happens in line 11 to 19: when we restart the example we don't want to start again withfoo0, so we store the counter inside Redis itself. The code above is designed to read this counter, or if the counter does not exist, to assign it the value of zero.
However note how it is a while loop, as we want to try again and again even if the cluster is down and is returning errors. Normal applications don't need to be so careful.
Lines between 21 and 30 start the main loop where the keys are set or an error is displayed.
Note the sleep call at the end of the loop. In your tests you can remove the sleep if you want to write to the cluster as fast as possible (relatively to the fact that this is a busy loop without real parallelism of course, so you'll get the usually 10k ops/second in the best of the conditions).
Normally writes are slowed down in order for the example application to be easier to follow by humans.
Starting the application produces the following output:
ruby ./example.rb ^C (I stopped the program here)
This is not a very interesting program and we'll use a better one in a moment but we can already try what happens during a resharding when the program is running.
*Resharding the cluster
Now we are ready to try a cluster resharding. To do this please keep the example.rb program running, so that you can see if there is some impact on the program running. Also you may want to comment thesleep call in order to have some more serious write load during resharding.
Resharding basically means to move hash slots from a set of nodes to another set of nodes, and like cluster creation it is accomplished using the redis-trib utility.
To start a resharding just type:
./redis-trib.rb reshard 127.0.0.1:7000
You only need to specify a single node, redis-trib will find the other nodes automatically.
Currently redis-trib is only able to reshard with the administrator support, you can't just say move 5% of slots from this node to the other one (but this is pretty trivial to implement). So it starts with questions. The first is how much a big resharding do you want to do:
How many slots do you want to move (from 1 to 16384)?
We can try to reshard 1000 hash slots, that should already contain a non trivial amount of keys if the example is still running without the sleep call.
Then redis-trib needs to know what is the target of the resharding, that is, the node that will receive the hash slots. I'll use the first master node, that is, 127.0.0.1:7000, but I need to specify the Node ID of the instance. This was already printed in a list by redis-trib, but I can always find the ID of a node with the following command if I need:
$ redis-cli -p 7000 cluster nodes | grep myself 97a3a64667477371c4479320d683e4c8db5858b1 :0 myself,master - 0 0 0 connected 0-5460
Ok so my target node is 97a3a64667477371c4479320d683e4c8db5858b1.
Now you'll get asked from what nodes you want to take those keys. I'll just typeall in order to take a bit of hash slots from all the other master nodes.
After the final confirmation you'll see a message for every slot that redis-trib is going to move from a node to another, and a dot will be printed for eve