Skip to content

Implement MultiStore with fallback mechanism

Nikola Milojevic requested to merge 14508-multi-store into master

What does this MR do and why?

This is part of the preparation work for our Sessions: Plan migration strategy

This MR is reimplementing a MultiStore that looks like a redis-rb Redis instance (which the Redis::Store inherits from). We're going to be reimplementing reads and writes separately so we can have a read-one-fallback/write-both state. It's easy to miss a method so we'll method_missing it to the SharedState Redis and keep track of it to add an implementation.

This ensures that anything unexpected behaves as it would before.

Note: This MultiStore will not be used yet. It will be used by Gitlab::Redis::Session.store and session_store in the future.

The MultiStore will talk directly/only to SharedState by default. Once the feature flag: use_multi_store is enabled, it will start writing to both Sessions(primary_store) SharedState (secondary_store), and read from Sessoins and fallback to the SharedState.

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/14508

Edited by Nikola Milojevic

Merge request reports