The new database API supports flagging queries as safe to run against a slave server if the site is using Master/slave replication. We should go through core and flag all queries that are "slave safe" while converting those queries to the new API. That should have no effect on most sites but on those using Master/slave replication (like Drupal.org) it should be a performance boost.

A query is slave-safe if it is OK if the data it retrieves is out of date by up to several minutes. Mostly that is true for reporting and statistical data, like the tracker module.

The current list of queries modified on Drupal.org to use a slave server would be a really good place to start. :-)

Comments

Crell’s picture

Crell commented
Version: 7.x-dev » 8.x-dev

We added a few, but I don't think Dries will let us add any more. :-( If you're running a big site with master/slave replication in Drupal 7, please give us feedback on what is and is not slave-safe! We can fold that data into Drupal 8 by just flagging more queries.

q0rban’s picture

q0rban commented

subscribe

ericduran’s picture

ericduran commented

Oh q0rban always a couple of days ahead of me :)

sub.

apotek’s picture

apotek commented

subscribe (running with the cool kids).

Crell’s picture

Crell commented
Issue summary: View changes
Status: Active » Fixed

In D8, the database connection is virtually always injected. That means you can swap the primary/replica connection per-service in the container configuration, or even inject both if you need. That means a global "check all the queries!" approach is no longer needed. Let's just close this out.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.