@@ -164,7 +164,7 @@ In a DB cluster we have many read replicas and one primary. A classic use of sca
By default, queries use read-only replicas, but due to [primary sticking](../administration/database_load_balancing.md#primary-sticking), GitLab sticks to using the primary for a certain period of time and reverts back to secondaries after they have either caught up or after 30 seconds, which can lead to a considerable amount of unnecessary load on the primary. In this [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56849) we introduced the `without_sticky_writes` block to prevent switching to the primary. Typically, this method can be applied to prevent primary stickiness after a trivial or insignificant write which doesn't affect the following queries in the same session. This [merge request example](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/57328) provides a good use case for when a usage timestamp update can lead the session to stick to the primary and how to prevent this by using `without_sticky_writes`.
As a counterpart of the above `without_sticky_writes` utility, this [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59167) introduces `use_replicas_for_read_queries`. This method forces all read-only queries inside its block to read replicas regardless of the current primary stickiness. This utility is reserved for the cases where those queries can tolerate the replication flags.
As a counterpart of the above `without_sticky_writes` utility, this [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59167) introduces `use_replicas_for_read_queries`. This method forces all read-only queries inside its block to read replicas regardless of the current primary stickiness. This utility is reserved for the cases where those queries can tolerate replication lag.
Internally, our database load balancer classifies the queries based on their main statement (`select`, `update`, `delete`, etc.). When in doubt, it redirects the queries to the primary database. Hence, there are some common cases the load balancer sends the queries to the primary unnecessarily:
...
...
@@ -173,7 +173,7 @@ Internally, our database load balancer classifies the queries based on their mai
- In-flight connection configuration set
- Sidekiq background jobs
Worse, after the above queries are executed, GitLab [sticks to the primary](../administration/database_load_balancing.md#primary-sticking). In [this merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56476), we introduced `fallback_to_replicas_for_ambiguous_queries` to make the inside queries prefer to use the replicas. That MR is also an example of how we redirected a costly, time-consuming query to the replicas.
Worse, after the above queries are executed, GitLab [sticks to the primary](../administration/database_load_balancing.md#primary-sticking). In [this merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59086), we introduced `fallback_to_replicas_for_ambiguous_queries` to make the inside queries prefer to use the replicas. That MR is also an example of how we redirected a costly, time-consuming query to the replicas.
