ReplicaKillSwitch::trigger() kills page cache for five minutes

Session is still used in Drupal 10, in ReplicaKillSwitch::trigger(). If this needs to be fixed, it needs to be fixed in the most recent Drupal version, first.

Whoa, 3 years ago I noticed this strange behavior on an old Drupal 7, I never checked on 8+ version.

If nothing changed since 7, there's room for improvement in db performance, almost no read requests use the slave db.

In Drupal 10, ReplicaKillSwitch::trigger() is called from SqlContentEntityStorage, which means that every time a content entity is deleted, restored, or saved, the session will be populated with that value.
api.drupal.org does not show other references to database.replica_kill_switch, which should mean those are the only methods/functions that call ReplicaKillSwitch::trigger().

If I recall it correctly (and it's the same Drupal 7 behavior), very few core mechanisms make usage of slave reading (comments ?).

So what's the point to keep this api if it's only legacy code that nobody uses

Using git grep --fixed-strings 'replica' -- '*.php', I found references to the database replica in the following files (leaving out the files containing test classes).

• core/modules/comment/src/CommentStatistics.php
• core/modules/node/src/Plugin/Search/NodeSearch.php
• core/modules/search/src/Plugin/views/argument/Search.php
• core/modules/search/src/SearchIndex.php
• core/modules/tracker/src/Controller/TrackerController.php
• core/modules/views/src/Plugin/views/query/Sql.php

Nice command line (I take note).

So what's the next move? Do you have a suggestion?

The next step would be to find another mechanism to use. Basing on that, a MR would be created to change the Drupal core code.

I agree that using a session value is "quite unusual" in this case, as that value would be stored for the currently logged in user, while whenever to use the replica server should hold true for every logged in user. I could delete many entities on a site; that should stop the replica server from being used for every user who access the site after that, since the changes I caused still needs to be propagated to the replica server.

A value stored using the keyvalue.expirable service could be used.