Giters

redis / jedis

Redis Java client

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Is renewSlotCache necessary when received MOVED

YorigamiShion opened this issue · comments

commented

Expected behavior

Just set JedisClusterInfoCache.slots[currentSlot] = targetConnection might be more efficient.

Actual behavior

When received MOVED, ClusterCommandExecutor will call ClusterConnectionProvider#renewSlotCache and then clear ``JedisClusterInfoCache.slots` and reassign them in a write lock.

Steps to reproduce:

Any action for redis server responses MOVED

  1. Send write command to slave node (e.g. failover)
  2. Send command to the node who does not owns the slot (usually after slot migration completed)
commented

We cannot fully adopt your suggestion because - i) Current implementation is based on Redis' proposed algorithm. ii) Usually MOVED happens to a large number of slots once; so renewing all is the faster way to update.

But I understand that for some users it might make more sense to renew slots one by one per MOVED. So we'll consider a PR that'll allow users to set a flag/config/param to update one slot (in slot cache) per MOVED instead of updating all slots.

commented

We cannot fully adopt your suggestion because - i) Current implementation is based on Redis' proposed algorithm. ii) Usually MOVED happens to a large number of slots once; so renewing all is the faster way to update.

But I understand that for some users it might make more sense to renew slots one by one per MOVED. So we'll consider a PR that'll allow users to set a flag/config/param to update one slot (in slot cache) per MOVED instead of updating all slots.

How about compare with previos cluster topology?
If MOVED to a new master, just change slot owner without renewSlotCache.
If MOVED to slot owner's slave, maybe failover happened, set all slots of the shard to new master or just renewSlotCache which is more safe.
Otherwise, call renewSlotCache.

commented

If MOVED to slot owner's slave, maybe failover happened, ...

"Maybe".
Maybe not.
What if the cluster is reconfigured where a replica (slave) is promoted to master with half of the slots?
Should a client library "guess" or fetch the information and use it?
To me, it's undoubtedly the later option.

If ..., just change slot owner without renewSlotCache.

Almost as I said in my previous comment.