Scheduling Azure Database for MySQL Flexible Server
Can ZopNight schedule Azure Database for MySQL Flexible Server?
Azure stops a MySQL Flexible Server only from the Ready state and starts any stopped server automatically after 30 days, a far longer leash than the 7-day databases. Compute halts while storage and backup meters continue, and servers in replication topologies refuse the stop entirely.
How the stop works
| Field | Value |
|---|---|
| Behaviour | stopped and started via the Flexible Server API, but only when the server is in the Ready state. |
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
Thirty days of leash
MySQL Flexible Server allows the longest stop on the Azure database shelf: a stopped server stays stopped for up to 30 days before the platform restarts it. Nightly and weekend schedules never approach the limit, but the month-long window also makes this one of the few databases where “stop it until the project resumes” is nearly practical, provided somebody diaries the restart for day 30.
Ready or skipped
The stop is attempted only against a server in the Ready state. A server mid-backup, mid-maintenance or otherwise busy at the stop hour is left alone. That is a soft skip, not a forced shutdown, which trades a night of savings for never corrupting an in-flight operation. If the skip happens repeatedly, the nightly maintenance and backup windows are colliding with the stop cron; move one of them.
Replication takes stop off the table
Servers wired into replication (a source with read replicas, or a replica itself) cannot be stopped. The topology has to come apart first, which is rarely worth it in production but highlights the real audience for this schedule: standalone dev, test and staging servers, which are also exactly the ones idling 118 hours a week.
The meters that keep spinning
Stopping halts compute billing. Provisioned storage bills at its full size, and backup storage beyond the free allowance bills too. A stopped server with a large provisioned disk keeps a real monthly floor, so quote the saving as the compute SKU’s hours, not the server’s whole line.
The morning buffer pool is empty
First connections after start find cold caches, and query latency takes a while to settle to its usual shape. Start the server ahead of the first application connection, and expect the connection pool to churn once as stale sockets are replaced.
A synthetic health check that connects immediately after the start cron absorbs that churn before any person or pipeline meets it.