The `use_model_load_balancing` results in a wrong sticking context used
This solves a subtle bug with `sticking` when `use_model_load_balancing` is used. The problem was that for `Web/Sidekiq`: 1. If prior request would have `use_model_load_balancing=false` it would see load balancers to be `main/main`. This would result in sticking context to include only `main`. 2. If next request would evaluate `use_model_load_balancing=true` it would see load balancers for `main/ci`, but would only for wal locations see `main=lag`. As a result we would not check replication lag against `ci`. 3. This result in a situation that if `ci` is way behind `main`, the 2. would not understand the state of `ci`. Thus would consider `ci` to be up-to date and stick to `main`. This commit fixes that: 1. If `ci:` is configured we always store the `ci:` in replication lag. This makes us the `wal_locations` (and `RackMiddleware` sticking context) to always include `main+ci` in all cases. 2. This results would behave (as for number of requests): we are reading primary / replica location from all databases. 3. Since we always have `ci` even if `use_model_load_balancing=false` we can properly evaluate state of replicas.
Showing
Please register or sign in to comment