dragonflydb / dragonfly

A modern replacement for Redis and Memcached
https://www.dragonflydb.io/
Other
24.46k stars 884 forks source link

support for redis configuation replica-read-only #3194

Open m1cha3lf opened 1 week ago

m1cha3lf commented 1 week ago

Hi,

i'm evaluating dragonflydb right now as an replacement for keydb. We have very large clusters with 50+ replicas. Each replica is also being used as local cache. On KeyDB / Redis we use the config key "replica-read-only / slave-read-only".

CONFIG SET replica-read-only no (error) ERR Unknown option or number of arguments for CONFIG SET - 'replica-read-only'

config get replica-read-only (empty array)

Would it be possible to support "replica-read-only" or the behavior to write against a slave?

Thanks in advance

Michael

romange commented 1 week ago

Sorry, I do not understand your use-case. What's your cluster topology? You have a single master with 50+ replicas? You have a cluster with 50 shards? What do you expect will happen when you write into a slave?

m1cha3lf commented 1 week ago

We have 1 primary KeyDB server and many replicas. (no cluster). Each replica is also being used from application servers as local cache. Do achieve that the application server has to write directly against replicas. (which is not working by default because replicas are read-only)

Basically the same as what DragonDB describes here: https://www.dragonflydb.io/faq/redis-replica-read-only-configuration

but this option doesn't seem to exist.

I'm aware that this might raise architecture design questions, but we do that with a good reason to keep latency low and high throughput.

romange commented 1 week ago

Frankly, it's the first time I am learning about such setup. So basically you are making sure that a slave writeable keyspace does not overlap with the master? @adiholden what do you think? Seems like a simple extension to add? @m1cha3lf Besides this writeability issue, have you already tested Dragonfly with replicating to 50 replicas?

m1cha3lf commented 1 week ago

Yes, the application is using a special prefix for all keys to avoid conflicts with keys coming from master.

i wasn't able to test the whole setup and replication due to the requirement of writing against a replica / slave.

romange commented 1 week ago

I think those unrelated. We've never tested master with 50 replicas so I prefer to hold on with this request until you are sure everything else works well