Update technical note for Object Cache with Drupal

[ccharlton]

D9 and D7 needed the steps that are no longer considered optional.

Closes #

Summary

Object Cache for Drupal - changes optional to recommended and makes sure D9 people see the info.

• Other prerequisites that must be completed before merging this PR

Release:

• When ready
• After date: $DATE

---

Post Launch

Do not remove - To be completed by the docs team upon merge:

• Redirect /old-path/ => /new-path/ (if applicable)
• Include/exclude pages ^ respectively within docs search service provider (if applicable)

[stevector]

@ccharlton are these tables not emptied by regular cache clears? I see the logic in emptying them, but I'm surprised we need to specify direct sql queries.

[ccharlton]

There are instances where stale data has snagged customers on setup. Moving the tip to recommended but not required seemed more appropriate than leaving it as optional.

[stevector]

But does the stale data get removed with a cache clear? I would rather recommending to customer that they click the cache clear button than they figure out (perhaps for the first time) how to directly run mysql commands against Pantheon.

[stevector]

@ccharlton, can you respond here?

[lcatlett]

@stevector and @ccharlton after Redis is enabled on a site, truncating the cache tables / bins that have moved to Redis storage is a required step and is not automatically done by enabling the Redis module, running drush cr, or clicking the cache clear button in the Pantheon dashboard. This is currently not documented in a stable release of the Redis module: https://www.drupal.org/project/redis/issues/3177375

If this step is skipped once Redis is enabled, the result is race conditions when invalidating cache which are incredibly difficult to diagnose and can result in very strange issues on the site - eg config appears to revert to old values after running a drush config:import after a deployment. The most failsafe approach is to just truncate all cache* tables which can be done with a direct mysql query, or via drush:

# Get a list of all cache tables
CACHETABLES="$(terminus drush <site>.<env> -- sql:query "SHOW TABLES LIKE 'cache%';")"

# Trucate each cache table in a loop to avoid resource contention and potential deadlocks.

for table in $CACHETABLES; do
    terminus drush <site>.<env> -- sql:query "TRUNCATE TABLE $table;"
done

[ccharlton]

@codyfishman posted his similar PR here: #9052