3 ms·
I don't think you understand what HA means. The app would look up in both databases. If it exists in any, there would be a session. Thisnis strictly different
by tossandthrow 4mo ago
I don't think you understand what HA means.
The app would look up in both databases. If it exists in any, there would be a session.
Thisnis strictly different from partitioning which I think you are mixing it up with.
Paritioning is for performance not HA
- 9dev 4mo agoThat’s the precise point I’m making
- n_e 4mo ago> The app would look up in both databases. If it exists in any, there would be a session. And if you find the session with differing values in both databases, how do you know which one is up-to-date? You need an algorithm to pick which data is right, such as electing a master instance. And that brings us back to the original discussion: to manage sessions (unlike caches) in a highly available way, you need to setup HA (or reimplement it, which obviously is a bad idea). You can't read round robin from multiple non-HA instances.
- tossandthrow 4mo agoYes, you are pointing out exactly how HA is difficult. There is a whole slew of downstream things you need to take into consideration.
- 9dev 4mo agoand as you've just confirmed... there is a need for good HA support in Redis. Which was the entire premise of this thread.