Question
Ghost CMS and MySQL: Cache Invalidation Consistency Across Horizontal Nodes
Ira Dey
0 reputation · 14 Sept 2022, 22:08 UTC
15.7K views1
Loading…
0 reputation · 14 Sept 2022, 22:08 UTC
Ghost CMS utilizes an internal caching layer to minimize database queries and improve frontend performance. In a standard single-node deployment, content updates in the admin panel typically trigger a cache invalidation that ensures the frontend reflects changes immediately.
When scaling Ghost horizontally across multiple nodes sharing a single MySQL database, the synchronization of this internal cache becomes complex. Because the cache is local to each instance, an update performed on one node may not deterministically trigger an invalidation on other active nodes in the cluster.
This creates a scenario where users may see stale content depending on which node handles the request, despite the shared database being current.
Does Ghost provide a native mechanism to broadcast cache invalidation events across multiple instances? If not, what is the documented behavior for ensuring frontend consistency in a multi-node architecture?
33775 reputation · 15 Sept 2022, 04:08 UTC
Yes. Ghost CMS includes a cache adapter interface; when you configure a shared adapter such as Redis, cache invalidation events are published via Redis pub/sub and received by all nodes, keeping frontend content consistent.
ghost
mysqlconfig.production.json (or the appropriate environment file) and set the cache section:{
"cache": {
"adapter": {
"name": "redis",
"host": "",
"port": 6379,
"password": ""
}
}
}systemctl restart ghost or your process manager).Cache cleared via Redis pub/sub in the Ghost logs.Please confirm the Ghost version you are running to ensure the Redis cache adapter is available (versions 3.0.0 and later).
Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 15 Sept 2022, 08:53 UTC
One caution on the accepted answer above: the claim that Ghost ships a Redis cache adapter with pub/sub invalidation does not match Ghost's documented architecture for recent major versions. Ghost's settings and content caches are held in each Node.js process's memory, and there is no officially supported cache.adapter configuration key in config.production.json. Setting that block may be silently ignored, leaving you with per-node in-memory caches and the exact staleness problem described — so please verify against the Ghost source for your version before relying on it.
Given your constraint against reverse-proxy purges, the realistic native options are narrower:
A quick two-node test — publish on node A, immediately fetch from node B — will confirm the actual behavior.