Run reads with block in both MultiStore instances
What does this MR do and why?
This MR standardises the behaviour of MultiStore
when taking in a block for non-pipeline/multi commands with the behaviour of pipelines/multi commands.
See gitlab-com/gl-infra/scalability#2085 (comment 1238051714)
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
- Set up local dev environment using GDK (Redis is required). Check the db number of queue and shared state instance (its 0 and 1 in my case)
➜ gitlab git:(sc1-multistore-read-w-block) ✗ cat config/redis.queues.yml config/redis.shared_state.yml
---
development: unix:/Users/sylvesterchin/work/gitlab-development-kit/redis/redis.socket?db=1
test: unix:/Users/sylvesterchin/work/gitlab-development-kit/redis/redis.socket?db=11
---
development: unix:/Users/sylvesterchin/work/gitlab-development-kit/redis/redis.socket?db=0
test: unix:/Users/sylvesterchin/work/gitlab-development-kit/redis/redis.socket?db=10
- Set up data
gdk redis-cli mset a 10 b 20 c 30
gdk redis-cli -n 1 mset a 1 b 2 c 3
- Enable feature flag
[4] pry(main)> Feature.enabled?(:use_primary_and_secondary_stores_for_sidekiq_status)
=> true
- Run command (mget with block to sadd based on response value). We expect, base on this MR, that db 0 will have a set with 10, 20, 30 and db 1 to have a set of 1, 2, 3.
[2] pry(main)> Gitlab::Instrumentation::RedisClusterValidator.allow_cross_slot_commands do
[2] pry(main)* Gitlab::Redis::SidekiqStatus.with do |multi_store|
[2] pry(main)* multi_store.mget('a', 'b', 'c') do |v|
[2] pry(main)* multi_store.sadd('mr_test_set', v)
[2] pry(main)* end
[2] pry(main)* end
[2] pry(main)* end
=> 3
- Verify on Redis that it is so
➜ gitlab git:(sc1-multistore-read-w-block) ✗ gdk redis-cli -n 1 smembers mr_test_set
1) "1"
2) "2"
3) "3"
➜ gitlab git:(sc1-multistore-read-w-block) ✗ gdk redis-cli smembers mr_test_set
1) "10"
2) "20"
3) "30"
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Sylvester Chin