Follower Clusters: Keeping a Working Copy of Production in Step
ScaleGrid’s follower clusters feature maintains a separate, synchronized copy of a production database for MongoDB, MySQL, or PostgreSQL. Unlike a one-time clone or a replica, this system imports data from the source on a scheduled basis, so the destination cluster stays current without burdening the primary system.
Because the two systems are independent, follower clusters offer flexibility that replication doesn’t. You can control how often the sync runs — as frequently as every day or as rarely as once a week — to limit load on the source. The follower is writable, so it can double as a staging area. You can also use different credentials or selectively strip data at the destination, though that filtering requires your own scripting. Follower clusters operate through storage snapshots, so they aren't available for in-memory offerings like Redis.
Better Tests with Production Data
Testing against synthetic data often fails to catch issues that surface with real-world workloads and data shapes. The safest fix is to validate code against a copy of production data. Privacy constraints aside, that approach holds up only as long as the test environment stays reasonably close to production, which is precisely where follower clusters help.
You can schedule regular imports from the production cluster into development and QA systems. These syncs rely on storage snapshots rather than logical dumps, so the refresh is nearly instantaneous. Whether you sync daily, weekly, or on another cadence, your staging environment benefits from data that reflects real production conditions — meaning tests that pass on it are much more likely to pass once deployed.
Dedicated Analytics Without Production Impact
Analytics jobs that scan large datasets are a common cause of unexpected production slowdowns. The first remedy is to offload that work to a secondary or replica node. But if the degradation still isn’t acceptable, running those queries on a dedicated analytics cluster is the next step.
Follower clusters make it easy to keep that analytics environment supplied with current production data. You can schedule a sync right before the analytics job runs, so the cluster has what it needs to execute. Since the entire sync is a snapshot restore without database-level operations, it introduces no extra load on the source cluster.
Cost-Effective Reporting Workflows
Reporting jobs are another workload that tends to run infrequently while consuming significant cluster resources. For teams that find this unacceptable, moving reporting to its own follower cluster keeps those resource-intensive queries isolated. To control costs, that reporting cluster can be sized smaller and paused when idle, then resumed for each scheduled run.
A typical reporting cycle with follower clusters might look like this:
- Use the resume API to bring the follower cluster back online.
- Confirm the cluster is in a running state via the get-status API.
- If reporting must run on updated data, trigger a backup on the production cluster — unless scheduled backups already make that unnecessary.
- Wait for the backup to finish.
- Call the sync job API on the follower to locate and restore the latest source snapshot.
- Wait for the sync to complete.
- Execute the reporting queries.
- Use the pause API to shut the cluster down until the next reporting interval.
More detail on configuring follower clusters is available in the documentation for MongoDB, MySQL, and PostgreSQL.
