CODEWITHSUNDEEP
redisredis-cluster
Max Holland
Max Holland

Reputation: 75

After Redis cluster reshard, lots of non contiguous slots assigned to a node

I created a redis cluster with three nodes:

~ redis-3.2.10/src/redis-trib.rb create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002

I then added a fourth node and resharded to make the slot allocation even:

~ redis-3.2.10/src/redis-trib.rb add-node 127.0.0.1:7003 127.0.0.1:7000
~ redis-3.2.10/src/redis-trib.rb reshard --timeout 60000  127.0.0.1:7000
...
How many slots do you want to move (from 1 to 16384)? 4096
...
Source node #1:all
...
redis-3.2.10/src/redis-trib.rb check 127.0.0.1:7000
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: 29fbb7e5f93eac22a224c14d4070139919bb0a5e 127.0.0.1:7000
   slots:1365-5460 (4096 slots) master
   0 additional replica(s)
M: c90c9f590bb48d328f3eed2fc96af3a7d9cb0f25 127.0.0.1:7003
   slots:0-1364,5461-6826,10923-12287 (4096 slots) master
   0 additional replica(s)
M: 970b3145574a4f38bbe10548bf6b80f8fdc2854d 127.0.0.1:7001
   slots:6827-10922 (4096 slots) master
   0 additional replica(s)
M: 2cc0922fcfb3e619b6d733e054dd249a4b6137bf 127.0.0.1:7002
   slots:12288-16383 (4096 slots) master
   0 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

Then if you scale back down, reshard the slots back from the :7003 node to the remaining three, you end up with something like:

>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: 29fbb7e5f93eac22a224c14d4070139919bb0a5e 127.0.0.1:7000
   slots:1365-5460,12288-13652 (5461 slots) master
   0 additional replica(s)
M: 970b3145574a4f38bbe10548bf6b80f8fdc2854d 127.0.0.1:7001
   slots:0-1364,5461-6826,10923-12287,13653-15017 (5461 slots) master
   0 additional replica(s)
M: 2cc0922fcfb3e619b6d733e054dd249a4b6137bf 127.0.0.1:7002
   slots:6827-10922,15018-16383 (5462 slots) master
   0 additional replica(s)
M: c90c9f590bb48d328f3eed2fc96af3a7d9cb0f25 127.0.0.1:7003
   slots: (0 slots) master
   0 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

The :7001 node has 4 different groups of hash slots assigned to it. After subsequent resharding this 'fragmentation' of hash slots seems to increase.

Could it ever become a problem (to performance or otherwise) having more and more fragmentation of hash slots?

Upvotes: 2

Views: 1469

Answers (2)

Sanjay Kanani
Sanjay Kanani

Reputation: 308

First Create Single node cluster. For that you need to edit redis_trib.rb file for min 3 node required validation.

After creating single node cluster just add other nodes and add consecutive slots in new node. By this way you will get what you want.

Upvotes: 0

Itamar Haber
Itamar Haber

Reputation: 49962

AFAIK no - hash slots' "fragmentation" is negligible in terms of any meaningful overheads. Some intuition:

  • Small range (16K)
  • Resharding isn't a frequent operation
  • Internally, Redis uses bitmaps to manage the slot mapping, so regardless of the actual slots' distribution accessing these bitmaps is done in constant time.

Upvotes: 1

Related Questions