You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/mysql/flexible-server/concepts-maintenance.md
+20-5Lines changed: 20 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,8 +4,8 @@ description: This article describes the scheduled maintenance feature in Azure D
4
4
ms.service: mysql
5
5
ms.subservice: flexible-server
6
6
ms.topic: conceptual
7
-
author: code-sidd
8
-
ms.author: sisawant
7
+
author: xboxeer
8
+
ms.author: yuzheng1
9
9
ms.custom: event-tier1-build-2022
10
10
ms.date: 05/24/2022
11
11
---
@@ -44,11 +44,26 @@ You can define system-managed schedule or custom schedule for each flexible serv
44
44
* With system-managed schedule, the system will pick any one-hour window between 11pm and 7am in your server's region time.
45
45
46
46
> [!IMPORTANT]
47
-
> Previously, a 7-day deployment gap between system-managed and custom-managed schedules was maintained. Due to evolving maintenance demands and the introduction of the [maintenance reschedule feature (preview)](#maintenance-reschedule-preview), we can no longer guarantee this 7-day gap.
47
+
> Previously, a 7-day deployment gap between system-managed and custom-managed schedules was maintained. Due to evolving maintenance demands and the introduction of the [maintenance reschedule feature (Public preview)](#maintenance-reschedule-public-preview), we can no longer guarantee this 7-day gap.
48
48
49
-
In rare cases, maintenance event can be canceled by the system or may fail to complete successfully. If the update fails, the update will be reverted, and the previous version of the binaries is restored. In such failed update scenarios, you may still experience restart of the server during the maintenance window. If the update is canceled or failed, the system will create a notification about the canceled or failed maintenance event respectively and notify you. The next attempt to perform maintenance will be scheduled as per your current scheduling settings and you will receive notification about it 5 days in advance.
50
49
51
-
## Maintenance reschedule (preview)
50
+
In rare cases, maintenance event can be canceled by the system or may fail to complete successfully. If the update fails, the update is reverted, and the previous version of the binaries is restored. In such failed update scenarios, you may still experience restart of the server during the maintenance window. If the update is canceled or failed, the system will create a notification about canceled or failed maintenance event respectively notifying you. The next attempt to perform maintenance will be scheduled as per your current scheduling settings and you will receive notification about it 5 days in advance.
51
+
52
+
## Near zero downtime maintenance (Public preview) ##
53
+
54
+
Azure Database for MySQL Flexible Server's "Near Zero Downtime Maintenance" feature is a groundbreaking development for **HA (High Availability) enabled servers**. This feature is designed to substantially reduce maintenance downtime, ensuring that in most cases, maintenance downtime is expected to be between 40 to 60 seconds. This capability is pivotal for businesses that demand high availability and minimal interruption in their database operations.
55
+
56
+
### Precise Downtime Expectations ###
57
+
-**Downtime Duration:** In most cases, the downtime during maintenance ranges from 10 to 30 seconds.
58
+
-**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 in the range of 40 to 60 seconds.
59
+
60
+
### Limitations and Prerequisites ###
61
+
To achieve the optimal performance promised by this feature, certain conditions and limitations should be noted:
62
+
63
+
-**Primary Keys in All Tables:** Ensuring that every table has a primary key is critical. Lack of primary keys can significantly increase replication lag, impacting the downtime.
64
+
-**Low Workload During Maintenance Times:** Maintenance periods should coincide with times of low workload on the server to ensure the downtime remains minimal. We encourage you to use the [custom maintenance window](how-to-maintenance-portal.md#specify-maintenance-schedule-options) feature to schedule maintenance during off-peak hours.
65
+
66
+
## Maintenance reschedule (Public preview)
52
67
53
68
> [!IMPORTANT]
54
69
> The maintenance reschedule feature is currently in preview. It is subject to limitations and ongoing development. We value your feedback to help enhance this feature. Please note that this feature is not available for servers using the burstable SKU.
0 commit comments