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-high-availability.md
+6-1Lines changed: 6 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -78,13 +78,18 @@ Azure Database for MySQL - Flexible Server forced failover enables you to manual
78
78
Forced failover triggers a failover that activates the standby replica to become the primary server with the same database server name by updating the DNS record. The original primary server is restarted and switched to the standby replica. Client connections are disconnected and need to be reconnected to resume their operations.
79
79
80
80
The overall failover time depends on the current workload and the last checkpoint. In general, it's expected to take between 60 and 120 seconds.
81
+
82
+
[!Note]Azure Resource Health event is generated in the event of planned failover, representing the failover time during which server was unavailable. The triggered events can be seen when clicked on "Resource Health" in the left pane. User initiated/ Manual failover is represented by status as **"Unavailable"** and tagged as **"Planned"**. Example - "A failover operation was triggered by an authorized user (Planned)". If your resource remains in this state for an extended period of time, please open a [support ticket](https://azure.microsoft.com/support/create-ticket/) and we will assist you.
83
+
81
84
82
85
### Unplanned: Automatic failover
83
86
84
87
Unplanned service downtime can be caused by software bugs or infrastructure faults like compute, network, or storage failures, or power outages that affect the availability of the database. If the database becomes unavailable, replication to the standby replica is severed and the standby replica is activated as the primary database. DNS is updated, and clients reconnect to the database server and resume their operations.
85
88
86
89
The overall failover time is expected to be between 60 and 120 seconds. But, depending on the activity in the primary database server at the time of the failover (like large transactions and recovery time), the failover might take longer.
87
90
91
+
[!Note]Azure Resource Health event is generated in the event of unplanned failover, representing the failover time during which server was unavailable. The triggered events can be seen when clicked on "Resource Health" in the left pane. Automatic failover is represented by status as **"Unavailable"** and tagged as **"Unplanned"**. Example - "Unavailable : A failover operation was triggered automatically (Unplanned)". If your resource remains in this state for an extended period of time, please open a [support ticket](https://azure.microsoft.com/support/create-ticket/) and we will assist you.
92
+
88
93
#### How automatic failover detection works in HA enabled servers
89
94
90
95
The primary server and the secondary server has two network endpoints,
@@ -139,7 +144,7 @@ Logs in ZRS are accessible even when the primary server is unavailable. This ava
139
144
Failovers are fully transparent from the client application. You don't need to take any action. Applications should just use the retry logic for their connections. </br>
140
145
141
146
-**What happens when I don't choose a specific zone for my standby replica? Can I change the zone later?**</br>
142
-
If you don't choose a zone, one will be randomly selected. It won't be the one used for the primary server. To change the zone later, you can set **High Availability** to **Disabled** on the **High Availability** pane, and then set it back to **Zone Redundant** and choose a zone.</br>
147
+
If you don't choose a zone, one will be randomly selected. It will be the one used for the primary server. To change the zone later, you can set **High Availability** to **Disabled** on the **High Availability** pane, and then set it back to **Zone Redundant** and choose a zone.</br>
143
148
144
149
-**Is replication between the primary and standby replicas synchronous?**</br>
145
150
The replication between the primary and the standby is similar to [semisynchronous mode](https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html) in MySQL. When a transaction is committed, it doesn't necessarily commit to the standby. But when the primary is unavailable, the standby does replicate all data changes from the primary to make sure there's no data loss.</br>
Copy file name to clipboardExpand all lines: articles/mysql/flexible-server/whats-new.md
+12Lines changed: 12 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,6 +23,18 @@ This article summarizes new releases and features in Azure Database for MySQL -
23
23
> This article contains references to the term slave, a term that Microsoft no longer uses. When the term is removed from the software, we'll remove it from this article.
24
24
25
25
26
+
27
+
## March 2023
28
+
29
+
**Azure Resource Health**
30
+
31
+
Use Azure Resource Health to monitor the health and availability of the HA enabled server in the event of planned or unplanned failover. [Learn more](concepts-high-availability.md)
32
+
33
+
**Enhanced restore experience**
34
+
35
+
Restore experience will now provide additional flexibility to modify the compute and storage setting during the provisioning of the restored server. Restored server can now be configured to have a higher compute tier, compute size and storage than that of the source server at the time of provisioning. Options like "Storage auto-grow", "Backup retention days" and "Geo-redundancy" can be also be edited to have a different value than that of source server.
0 commit comments