Scheduled maintenance in Azure Database for MySQL

Azure Database for MySQL performs periodic maintenance to help keep your managed database secure, stable, and up to date. During maintenance, the server gets new features, updates, and patches.

The following sections describe the maintenance types. For specific details about what each maintenance update entails, refer to the release notes. These notes provide comprehensive information about the updates applied during maintenance, so that you can understand and prepare for any changes that affect your environment.

Our standard maintenance cycle is no less frequent than every 30 days. This period helps ensure system stability and performance while minimizing disruption to your services.

In certain scenarios, such as the need to deploy urgent security fixes or updates that are critical to maintaining availability and data integrity, we might conduct maintenance more frequently. These exceptions help safeguard your data and ensure the continuous operation of your services.

You can schedule maintenance during a specific day of the week and a time window within that day. Or you can let the system pick a day and a time window for you automatically. Either way, the system alerts you seven days before it runs any maintenance. The system also tells you when maintenance starts and when it successfully finishes.

Notifications about upcoming scheduled maintenance can be:

• Emailed to a specific address.
• Emailed to an Azure Resource Manager role.
• Sent in a text message (SMS) to mobile devices.
• Pushed as a notification to an Azure app.
• Delivered as a voice message.

When you specify preferences for the maintenance schedule, you can pick a day of the week and a time window. If you don't specify preferences, the system picks times between 11 PM and 7 AM in your server's region time. You can define different schedules for each flexible server in your Azure subscription.

You can update scheduling settings at any time. If maintenance is scheduled for your flexible server and you update scheduling preferences, the current rollout proceeds as scheduled. The change to scheduling settings becomes effective upon its successful completion for the next scheduled maintenance.

You can define a system-managed schedule or a custom schedule for each flexible server in your Azure subscription:

• With a custom schedule, you can specify your maintenance window for the server by choosing the day of the week and a one-hour time window.
• With a system-managed schedule, the system picks any one-hour window between 11 PM and 7 AM in your server's region time.

In rare cases, a maintenance event can be canceled by the system or might fail to finish successfully. If a maintenance event fails, the update is reverted, and the previous version of the binaries is restored. In scenarios of failed updates, you might still experience a restart of the server during the maintenance window.

If a maintenance event is canceled or fails, the system sends you a notification. The next attempt to perform maintenance is scheduled according to your current settings. You receive a notification about the next attempt five days in advance.

The Azure Database for MySQL near-zero-downtime maintenance feature is a groundbreaking development for high-availability servers. This feature is designed to substantially reduce maintenance downtime. This capability is pivotal for businesses that demand high availability and minimal interruption in their database operations.

• Downtime duration: In most cases, the downtime during maintenance ranges from 10 to 30 seconds.
• Additional considerations: After a failover event, there's an inherent DNS time-to-live (TTL) period of approximately 30 seconds. This period isn't directly controlled by the maintenance process but is a standard part of DNS behavior. So, from a customer's perspective, the total downtime experienced during maintenance could be 40 to 60 seconds.

To achieve the optimal performance that this feature offers, note these conditions and limitations:

• Primary keys in all tables: Ensuring that every table has a primary key is critical. A lack of primary keys can significantly increase replication lag and affect the downtime.
• Low workload during maintenance times: Maintenance periods should coincide with times of low workload on the server to minimize downtime. We encourage you to use the custom maintenance window to schedule maintenance during off-peak hours.
• Downtime guarantees: Although we strive to keep the maintenance downtime as low as possible, we don't guarantee that it will be less than 60 seconds in all circumstances. Various factors, such as high workload or specific server configurations, can increase downtime. In the worst-case scenario, downtime might be similar to that of a standalone server.

The maintenance rescheduling feature gives you greater control over the timing of maintenance activities on your Azure Database for MySQL flexible server. After you receive a maintenance notification, you can reschedule it to a more convenient time, whether it was system managed or custom managed.

Use this feature to avoid disruptions during critical database operations. We encourage your feedback as we continue to develop this functionality.

Rescheduling isn't confined to fixed time slots. It depends on the earliest and latest permissible times in the current maintenance cycle. The cycle typically spans from the first day to the last day of the maintenance window for the region. When you reschedule, you get a notification to confirm the changes, according to the standard notification policies.

Be aware of the following points about the feature:

• Tier availability: Maintenance rescheduling isn't available for the Burstable compute tier. This feature is intended for servers in the production environment, whereas the Burstable tier is designed for non-production purposes.
• Demand constraints: Your rescheduled maintenance might be canceled if a high number of maintenance activities occur simultaneously in the same region.
• Lock-in period: Rescheduling is unavailable 15 minutes before the initially scheduled maintenance time, to maintain the reliability of the service.
• Rescheduling throttle: If too many servers in the same region are scheduled for maintenance during the same time, rescheduling requests might fail. If this failure occurs, you receive an error notification that advises you to choose an alternative time slot. Successfully rescheduled maintenance is unlikely to be canceled.

There's no limitation on how many times a maintenance event can be rescheduled. As long as a maintenance event hasn't entered the In preparation state, you can always reschedule it to another time.

The maintenance start times differ across regions. Servers in different regions might receive maintenance notifications at different times.

It's possible that the servers that didn't receive notifications were created more recently, and the system determined that they don't yet need maintenance.

No, opting out of scheduled maintenance isn't allowed. However, you can use the maintenance rescheduling feature to adjust the timing. Or you can enable the high-availability feature to minimize downtime. Because Azure Database for MySQL is a platform as a service (PaaS) database product, performing timely maintenance helps ensure the security and reliability of your database.

• Change the maintenance schedule
• Get notifications about upcoming maintenance
• Set up alerts about upcoming scheduled maintenance events