(please feel free to join the discussion at
https://github.com/redis/redis/discussions/9760)
TL;DR Since time immemorial, Redis has allowed stand-alone and cluster replicas to be configured so they can accept write requests. If you have an opinion about this feature, please add your voice to this discussion.
The primary use of Redis replicas is to provide a highly-available database service via failover and promotion. Replicas can also be used to offload reads from the master. However, a client can write to a replica under certain conditions (with the proper configuration and/or connection settings).
The motivations for making replicas writable, as far as we're aware, were mainly to support these use cases:
a. Allow creating (and possibly deleting) temporary keys, such as those that ZUNIONSTORE produces
b. Allow using commands that have the potential to write to keys, even if they don't necessarily do so, such as with using SORT in its read-only invocation form.
However, with Redis v6.2 and the upcoming v7, a slew of new _RO commands and complementary non-STORE variants have been added to address just that.
If that's indeed the case, namely that writable replicas are no longer really needed, the next question is whether they are needed at all. Supporting write replicas not only adds to the overall complexity of the project but also introduces several edge cases that, while rare, have damage potential during runtime. While the effort can be invested to address some/all of the issues, we're looking to assess the need and requirements from the feature.
So the questions we are looking to answer are mainly:
1. Are you using/have used Redis' writable replicas? If yes, what is/was the use case?
2. If you've answered yes to the above, are you writing to keys that also exist on the master?
3. And, if yes is your answer to the first question, are the keys written to the replica set with a TTL so they'll expire?
Thanks in advance for your participation!
--
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.