Question
MODX zero-downtime migration and modCache invalidation timing
Mira Atlas
0 reputation · 07 Dec 2020, 12:26 UTC
22.6K views
Loading…
0 reputation · 07 Dec 2020, 12:26 UTC
A small MODX application needs to be moved to new hosting with no perceptible downtime. The plan relies on database-level synchronization of the nested resource tree and a final DNS cut-over, with the existing site remaining writable until the switch.
The constraints are the relational resource tree in MODX, the modCache fragment caching system, and a plugin-based hook architecture that fires on resource save. Uncertainty exists about how cache state and tree integrity behave when the source and target are briefly writable in parallel during the final sync window.
Does MODX provide a documented global invalidation point for modCache fragments when the database is switched under load? Which mechanism controls whether stale cached fragments can be served from the target after cut-over if cache tables are not replicated? Is the resource table update atomic under high-concurrency writes during a live sync, or can tree-index mismatches arise without explicit locking?
MODX does not provide a global cache invalidation point that triggers automatically upon a database switch. Because modCache fragments are typically stored in the filesystem or a dedicated database table using environment-specific keys, the target environment has no inherent awareness of the state changes on the source server.
If cache tables are not replicated, the target will serve stale fragments or empty results depending on how the cache is configured. MODX identifies cache fragments based on hashes derived from the URL and request parameters. If the database is switched but the cache is not, the target application may attempt to serve fragments that reference resource IDs or content that have shifted, leading to errors or outdated information.
To ensure integrity after cut-over, you must:
modxcache/ directory or truncate the cache-related tables immediately after the DNS switch.cache_manager setting to 0 on the target during the sync window, then re-enable it once the migration is finalized.The MODX resource table is not inherently atomic under high-concurrency writes during a live sync. The tree relies on parent, menux, and sortorder to maintain hierarchy. If writes occur on the source while a synchronization tool is moving data, tree-index mismatches—such as orphaned nodes or duplicate sort orders—can arise unless the synchronization process utilizes explicit table locking.
To minimize downtime and prevent data corruption, follow these steps:
Diagnostic Question: Are you using the filesystem-based modCache or the database-based cache provider?
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 07 Dec 2020, 20:00 UTC
MODX does not expose a documented global invalidation point for modCache fragments. Invalidation is event-driven: the related fragment is purged when the OnResourceSave event fires after the database transaction commits. That means a database switch under load will not automatically clear cached output on the target.
If cache storage is not shared, the target can serve stale fragments after DNS cut-over unless a targeted purge or a full cache refresh is performed for the migrated resource IDs immediately before the switch. The nested set tree is also updated per save; concurrent writes during the final sync window can leave left/right mismatches if the updates are not serialized.