Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PLATFORM-9062 | Allow Cargo to use replica databases #19

Merged
merged 4 commits into from
Mar 5, 2024

Conversation

mszabo-wikia
Copy link

@mszabo-wikia mszabo-wikia commented Feb 15, 2024

The Cargo extension currently uses a single database connection to access and manage its database tables, managed entirely by CargoUtils without going through the usual MW DBAL layers. This ipso facto precludes the use of a proper primary - replica setup, as this connection must allow database writes. We want to do just that, so that we can offload read queries to replicas where possible and avoid putting undue load on the primary DB in an active-active world. So, first make it possible for Cargo to utilize replicas at all by factoring out its DB connection management logic into a new class that can be optionally configured to use the MW DBAL to obtain DB connections while keeping backwards compatibility with the existing setup.

With this done, the main source of primary DB access in Cargo - the cargo_query parser function, which often gets run in case of parser cache misses - can actually be switched to use a replica, as it does not really need to read from the primary. However, one may imagine a case where it is necessary for a query to lead the latest and greatest data from the primary, e.g. on a page that stores some data via cargo_store then queries some of that data via cargo_query further down the line. Sidestep this by leveraging MW's hasOrMadeRecentPrimaryChanges() helper to always return a primary DB connection irrespective of the caller, if writes have been detected on the configured Cargo LB.

Change-Id: I5ed6661f46be257d1ea6b194aaccbbc5b02c406a

@mszabo-wikia mszabo-wikia force-pushed the PLATFORM-9062-bp branch 2 times, most recently from 5f918be to 0384d8c Compare February 15, 2024 23:36
The Cargo extension currently uses a single database connection to
access and manage its database tables, managed entirely by CargoUtils
without going through the usual MW DBAL layers. This ipso facto
precludes the use of a proper primary - replica setup, as this
connection must allow database writes. We want to do just that, so that
we can offload read queries to replicas where possible and avoid putting
undue load on the primary DB in an active-active world. So, first make
it possible for Cargo to utilize replicas at all by factoring out its DB
connection management logic into a new class that can be optionally
configured to use the MW DBAL to obtain DB connections while keeping
backwards compatibility with the existing setup.

With this done, the main source of primary DB access in Cargo - the
cargo_query parser function, which often gets run in case of parser
cache misses - can actually be switched to use a replica, as it does not
really need to read from the primary. However, one may imagine a case
where it is necessary for a query to lead the latest and greatest data
from the primary, e.g. on a page that stores some data via cargo_store
then queries some of that data via cargo_query further down the line.
Sidestep this by leveraging MW's hasOrMadeRecentPrimaryChanges() helper
to always return a primary DB connection irrespective of the caller, if
writes have been detected on the configured Cargo LB.

This code has not yet been actually tested - I am submitting this to
gather opinions and suggestions.

Change-Id: I5ed6661f46be257d1ea6b194aaccbbc5b02c406a
…argoAttach, CargoDeclare and CargoPageValues

Some of the actions are still using PRIMARY DB connection during the Read requests, and therefore we should replace them with use of the proper REPLICA DB. All of those cases are simple and shouldn't yield any errors when PRIMARY DB is not used to query the results.
Also, mark CargoRecreateTablesAPI as writing API to minimise noise from transaction profile.
@mszabo-wikia mszabo-wikia force-pushed the PLATFORM-9062-bp branch 2 times, most recently from 4ce06bb to e86f124 Compare February 29, 2024 10:24
@harnash harnash merged commit 952a358 into REL1_39 Mar 5, 2024
2 checks passed
@harnash harnash deleted the PLATFORM-9062-bp branch March 5, 2024 10:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants