Skip to content

Commit 8cc246b

Browse files
committed
updating whats new and few other changes
1 parent 70ac058 commit 8cc246b

File tree

3 files changed

+20
-3
lines changed

3 files changed

+20
-3
lines changed

articles/mysql/flexible-server/concepts-high-availability.md

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -78,13 +78,18 @@ Azure Database for MySQL - Flexible Server forced failover enables you to manual
7878
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.
7979

8080
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+
8184

8285
### Unplanned: Automatic failover
8386

8487
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.
8588

8689
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.
8790

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+
8893
#### How automatic failover detection works in HA enabled servers
8994

9095
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
139144
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>
140145

141146
- **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>
143148

144149
- **Is replication between the primary and standby replicas synchronous?**</br>
145150
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>

articles/mysql/flexible-server/overview.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -177,13 +177,13 @@ One advantage of running your workload in Azure is its global reach. The flexibl
177177
| Central US | :heavy_check_mark: | :heavy_check_mark: | :x: | :heavy_check_mark: |
178178
| China East 2 | :heavy_check_mark: | :heavy_check_mark: | :x: | :x: |
179179
| China North 2 | :heavy_check_mark: | :heavy_check_mark: | :x: | :x: |
180-
| China North 3 | :heavy_check_mark: | :heavy_check_mark: | :x: | :x: |
180+
| China North 3 | :heavy_check_mark: | :heavy_check_mark: | :x: | :heavy_check_mark: |
181181
| East Asia (Hong Kong) | :heavy_check_mark: | :heavy_check_mark: | :x: | :heavy_check_mark: |
182182
| East US | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
183183
| East US 2 | :heavy_check_mark: | :heavy_check_mark: | :x: | :heavy_check_mark: |
184184
| France Central | :heavy_check_mark: | :heavy_check_mark: | :x: | :heavy_check_mark: |
185185
| France South | :heavy_check_mark: | :heavy_check_mark: | :x: | :heavy_check_mark: |
186-
| Germany West Central | :heavy_check_mark: | :heavy_check_mark: | :x: | :x: |
186+
| Germany West Central | :heavy_check_mark: | :heavy_check_mark: | :x: | :heavy_check_mark: |
187187
| Japan East | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
188188
| Japan West | :heavy_check_mark: | :heavy_check_mark: | :x: | :heavy_check_mark: |
189189
| Korea Central | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |

articles/mysql/flexible-server/whats-new.md

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -23,6 +23,18 @@ This article summarizes new releases and features in Azure Database for MySQL -
2323
> 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.
2424
2525

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.
36+
37+
2638
## February 2023
2739

2840
- **Enhanced metrics workbook is now available**

0 commit comments

Comments
 (0)