Redis ClusterSharedState clean up post-migration
The clean-up work would involve:
-
RemoveMultiStore
usage inSharedState
and letself.pool
return a single connection toClusterSharedState.pool
. SinceClusterSharedState
has a fallback config toSharedState
, it would not affect SM users. The benefit is that we can clean up without introducing extra Redis connections on the application side.Avoid increasing the connections excessively in step 3 (since that causesredis.shared_state.yml
andredis.cluster_shared_state.yml
to be identical)
-
Remove usage of ClusterSharedState
and skip its connection pool initialisation since it is used in MultiStore only. This will reduce the connection usage by half. During the transition period in the next step, the connection usage would only return to the same level as during migration. -- gitlab-org/gitlab!139617 (merged) -
~~Updating chef and k8s-workloads/gitlab-com to use ServiceRedisClusterSharedState in place of Redis Persistent~~ -
Updating GitLab Rails to remove Gitlab::Redis::ClusterSharedState
class and update all usages toSharedState
. More details in #2651 (comment 1693732965) -
Clean out redis_cluster_shared_state
usage in chef and k8s-workloads/gitlab-com. -
Decommission Redis persistent after 1-2 weeks of observation.We no longe decommission ServiceRedis as part of this wider epic since buffered counter workload is still on the Redis Cluster