Scheduling Memorystore for Redis
Can ZopNight schedule Memorystore for Redis?
Memorystore scheduling scales the replica count down for quiet hours and restores it later. The primary node keeps running, keeps serving and keeps billing all night. Savings equal the removed replicas' node-hours, the cache stays warm with 0 morning rebuild, and overnight failover protection is what gets traded.
How the stop works
| Field | Value |
|---|---|
| Behaviour | scales the replica count down to reduce billing during quiet hours, restoring replicas on resume |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
A schedule that never stops the instance
Redis holds state in memory, so powering it off nightly would mean losing or reloading the dataset every day. The Memorystore schedule does not try: the primary stays up around the clock, and the lever is the replica count, scaled down in the evening and back up before business hours. Applications keep reading and writing all night as if nothing happened, because for the primary, nothing did.
The saving is counted in replica node-hours
Each read replica is a full node billing the instance’s per-GB-hour rate. An instance sized at 10 GB with 2 replicas spends two-thirds of its bill on replica capacity; dropping to zero replicas overnight halves-plus the nightly cost while leaving the working dataset untouched. The primary’s own node-hours are the floor no Redis schedule can cross.
What thins out overnight
Replicas are not decorative. With fewer of them, automatic failover has fewer candidates. At zero, a primary failure at 3am means downtime rather than promotion, and read throughput concentrates on the primary. Production caches fronting real overnight traffic should keep at least 1 replica; the aggressive zero-replica window belongs to dev, staging and internal-tools instances whose 3am availability contract is theoretical.
No cold cache in the morning
Alone among the data services on this directory, the scheduled resource wakes with its performance fully intact: the primary never flushed, so the 8am hit rate equals the 7pm hit rate. Restoring replicas is a background sync from the primary, invisible to clients. The usual warm-up choreography other schedules require simply does not exist here.
Timing the restore
Replica re-sync takes time proportional to dataset size. Restore an hour before peak so failover protection and read capacity are back in place before traffic arrives. The sync is cheap, but it is not instantaneous.
Keep an eye on primary CPU during the window as well: the reads the replicas were absorbing all land on a single node overnight.