Merge pull request #281349 from markingmyname/tam2

[MySQL] minor edits to MySQL related content

Author: Jill Grant

articles/mysql/migrate/migrate-single-flexible-in-place-auto-migration.md

@@ -3,8 +3,8 @@ title: In-place automigration
 description: This tutorial describes how to configure notifications, review migration details and FAQs for an Azure Database for MySQL Single Server instance schedule for in-place automigration to Flexible Server.
 author: adig
 ms.author: adig
-ms.reviewer: maghan, talawren
-ms.date: 05/21/2024
+ms.reviewer: talawren, maghan
+ms.date: 07/19/2024
 ms.service: mysql
 ms.subservice: flexible-server
 ms.topic: overview
@@ -19,16 +19,16 @@ ms.custom:
 
 **In-place automigration** from Azure Database for MySQL – Single Server to Flexible Server is a service-initiated in-place migration during planned maintenance window for Single Server database workloads with **Basic, General Purpose or Memory Optimized SKU**, data storage used **<= 100 GiB** and **no complex features (CMK, Microsoft Entra ID, Read Replica, Virtual Network, Double Infra encryption, Service endpoint/VNet Rules) enabled**. The eligible servers are identified by the service and are sent an advance notification detailing steps to review migration details.
 
-> [!IMPORTANT]  
-> Some Single Server instances may require mandatory inputs to perform a successful in-place automigration. Review the migration details in the Migration blade on Azure portal to provide those inputs. Failure to provide mandatory inputs 7 days before the scheduled migration will lead to re-scheduling of the migration to a later date.  
+> [!IMPORTANT]
+> Some Single Server instances might require mandatory inputs to perform a successful in-place automigration. Review the migration details in the Migration blade on Azure portal to provide those inputs. Failure to provide mandatory inputs 7 days before the scheduled migration will lead to re-scheduling of the migration to a later date.
 
 The in-place migration provides a highly resilient and self-healing offline migration experience during a planned maintenance window, with less than **5 mins** of downtime. It uses backup and restore technology for faster migration time. This migration removes the overhead to manually migrate your server and ensure you can take advantage of the benefits of Flexible Server, including better price & performance, granular control over database configuration, and custom maintenance windows. Following described are the key phases of the migration:
 
 - **Target Flexible Server is deployed**, inheriting all feature set and properties (including server parameters and firewall rules) from source Single Server. Source Single Server is set to read-only and backup from source Single Server is copied to the target Flexible Server.
 - **DNS switch and cutover** are performed successfully within the planned maintenance window with minimal downtime, allowing maintenance of the same connection string post-migration. Client applications seamlessly connect to the target flexible server without any user driven manual updates. In addition to both connection string formats (Single and Flexible Server) being supported on migrated Flexible Server, both username formats – username@server_name and username are also supported on the migrated Flexible Server.
 - The **migrated Flexible Server is online** and can now be managed via Azure portal/CLI. Stopped Single Server is deleted seven days after the migration.
 
-> [!NOTE]  
+> [!NOTE]
 > If your Single Server instance has General Purpose V1 storage, your scheduled instance will undergo an additional restart operation 12 hours prior to the scheduled migration time. This restart operation serves to enable the log_bin server parameter needed to upgrade the instance to General Purpose V2 storage before undergoing the in-place auto-migration.
 
 ## Eligibility
@@ -50,19 +50,19 @@ Following described are the ways to check and configure automigration notificati
 Following described are the ways to review your migration schedule once you receive the in-place automigration notification:
 
 > [!NOTE]  
-> The migration schedule will be locked 7 days prior to the scheduled migration window after which you'll be unable to reschedule.
+> The migration schedule is locked 7 days prior to the scheduled migration window after which you'll be unable to reschedule.
 
 - The **Single Server overview page** for your instance displays a portal banner with information about your migration schedule.
 - For Single Servers scheduled for automigration, a new **Migration blade** is lighted on the portal. You can review the migration schedule by navigating to the Migration blade of your Single Server instance.
 - If you wish to defer the migration, you can defer by a month at a time by navigating to the Migration blade of your single server instance on the Azure portal and rescheduling the migration by selecting another migration window within a month.
 - If your Single Server has **General Purpose SKU**, you have the other option to enable **High Availability** when reviewing the migration schedule. As High Availability can only be enabled during create time for a MySQL Flexible Server, it's highly recommended that you enable this feature when reviewing the migration schedule.
-- If your Single Server has **private endpoints**, perform the following **mandatory** steps when reviewing the migration schedule atleast 7 days before the scheduled migration:
+- If your Single Server has **private endpoints**, perform the following **mandatory** steps when reviewing the migration schedule at least 7 days before the scheduled migration:
   - **Review** the private endpoints listed to be migrated. Ensure they are marked as **Ready to Migrate**. If they are marked as ineligible, select the appropriate subscription and private DNS Zone.
-  - Select the **confirmation checkbox** after performing the listed pre-requisite checks for migrating private endpoints.
-  - Click on the **Authenticate** button to authenticate ARM connection required to migrate the private endpoints from source to target server.
-  - Click on **Save** to save all the above steps.
+  - Select the **confirmation checkbox** after performing the listed prerequisite checks for migrating private endpoints.
+  - Select the **Authenticate** button to authenticate ARM connection required to migrate the private endpoints from source to target server.
+  - Select on **Save** to save all the above steps.
   > [!NOTE]  
-  > If the mandatory inputs for migration are not provided atleast 7 days before the scheduled migration, the migration will be rescheduled to a later date.
+  > If the mandatory inputs for migration are not provided at least 7 days before the scheduled migration, the migration is rescheduled to a later date.
 
 ## Prerequisite checks for in-place automigration
 
@@ -116,9 +116,9 @@ Here's the info you need to know post in-place migration:
 
 | **Property** | **Configuration** |
 | --- | --- |
-| Suppress specific alert types | Disable specific alert types with the Microsoft Defender for Cloud platform. For more information, visit [Suppress alerts from Microsoft Defender for Cloud guide](../../defender-for-cloud/alerts-suppression-rules.md). <br /><br /> Single Server users can use the API property: <br /> `properties.disabledAlerts` |
-| Email notifications | Define email notification for Microsoft Defender for Cloud Alerts for all resources in a subscription. For more information, visit [Configure email notifications for security alerts](../../defender-for-cloud/configure-email-notifications.md). <br /><br /> Single Server users can use the API properties: <br /> `properties.emailAccountAdmins`, <br /> `properties.emailAddresses` |
-| Export alerts for further processing and/or archiving | Alerts are stored in the Microsoft Defender for Cloud platform and exposed through the Azure Resource Graph. <br /> You can export alerts to a different store and manage retention separately. For more information, visit [Set up continuous export in the Azure portal - Microsoft Defender for Cloud](../../defender-for-cloud/continuous-export.md). <br /><br /> Single Server users can use the API properties: <br /> `properties.retentionDays`, <br /> `properties.storageAccountAccessKey`, <br /> `properties.storageEndpoint` |
+| Suppress specific alert types | Disable specific alert types with the Microsoft Defender for Cloud platform. For more information, visit [Suppress alerts from Microsoft Defender for Cloud guide](../../defender-for-cloud/alerts-suppression-rules.md).<br /><br />Single Server users can use the API property:<br />`properties.disabledAlerts` |
+| Email notifications | Define email notification for Microsoft Defender for Cloud Alerts for all resources in a subscription. For more information, visit [Configure email notifications for security alerts](../../defender-for-cloud/configure-email-notifications.md).<br /><br />Single Server users can use the API properties:<br />`properties.emailAccountAdmins`,<br />`properties.emailAddresses` |
+| Export alerts for further processing and/or archiving | Alerts are stored in the Microsoft Defender for Cloud platform and exposed through the Azure Resource Graph.<br />You can export alerts to a different store and manage retention separately. For more information, visit [Set up continuous export in the Azure portal - Microsoft Defender for Cloud](../../defender-for-cloud/continuous-export.md).<br /><br />Single Server users can use the API properties:<br />`properties.retentionDays`,<br />`properties.storageAccountAccessKey`,<br />`properties.storageEndpoint` |
 
 ## Frequently Asked Questions (FAQs)
 
@@ -139,7 +139,7 @@ Here's the info you need to know post in-place migration:
 
 **Q. How can I defer the scheduled migration?​**
 
-**A.** You can review the migration schedule by navigating to the Migration blade of your Single Server instance. If you wish to defer the migration, you can defer by a month at the most by navigating to the Migration blade of your single server instance on the Azure portal and rescheduling the migration by selecting another migration window within a month. The migration details will be locked seven days prior to the scheduled migration window after which you're unable to reschedule. This in-place migration can be deferred monthly until 16 September 2024.
+**A.** You can review the migration schedule by navigating to the Migration blade of your Single Server instance. If you wish to defer the migration, you can defer by a month at the most by navigating to the Migration blade of your single server instance on the Azure portal and rescheduling the migration by selecting another migration window within a month. The migration details are locked seven days prior to the scheduled migration window after which you're unable to reschedule. This in-place migration can be deferred monthly until 16 September 2024.
 
 **Q. What username and connection string would be supported for the migrated Flexible Server? ​​**
 

articles/mysql/migrate/whats-happening-to-mysql-single-server.md

@@ -1,9 +1,9 @@
 ---
 title: What's happening to Azure Database for MySQL single server?
 description: The Azure Database for MySQL - Single Server service is being deprecated.
-author: markingmyname
-ms.author: maghan
-ms.reviewer: adig, talawren
+author: adig
+ms.author: adig
+ms.reviewer: talawren, magha
 ms.date: 05/21/2024
 ms.service: mysql
 ms.subservice: single-server
@@ -48,7 +48,7 @@ For more information on migrating from Single Server to Flexible Server using ot
 - If your source Azure Database for MySQL Single Server has engine version v8.x, ensure to upgrade your source server's .NET client driver version to 8.0.32 to avoid any encoding incompatibilities post migration to Flexible Server.
 - If your source Azure Database for MySQL Single Server has engine version v8.x, ensure to upgrade your source server's TLS version from v1.0 or v1.1 to TLS v1.2 before the migration as the older TLS versions have been deprecated for Flexible Server.
 - If your source Azure Database for MySQL Single Server utilizes nondefault ports such as 3308,3309 and 3310, change your connectivity port to 3306 as the above mentioned nondefault ports aren't supported on Flexible Server.
-- Service tags (SQL) in Outbound Rules are not supported on Azure Database for MySQL Flexible Server. Please use Fully Qualified Domain name(FQDN) in Outbound Rules when configuring teh firewall settings for the Flexible Server.
+- Service tags (SQL) in Outbound Rules are not supported on Azure Database for MySQL Flexible Server. Please use Fully Qualified Domain name(FQDN) in Outbound Rules when configuring the firewall settings for the Flexible Server.
 
 ## What happens post sunset date (September 16, 2024)?
 
@@ -122,19 +122,21 @@ When you migrate from Azure Database for MySQL - Single Server to Flexible Serve
 
 **Q. What happens to my existing Azure Database for MySQL single server instances?**
 
-**A.** Your existing Azure Database for MySQL single server workloads continues to function as before and will be officially supported until the sunset date. However, no new updates are released for Single Server and we strongly advise you to start migrating to Azure Database for MySQL Flexible Server at the earliest. Post the sunset date, your Single Server instance, along with its data files, will be [force-migrated](./whats-happening-to-mysql-single-server.md#forced-migration-post-sunset-date) to an appropriate Flexible Server instance in a phased manner.
+**A.** Your existing Azure Database for MySQL single server workloads continues to function as before and is officially supported until the sunset date. However, no new updates are released for Single Server and we strongly advise you to start migrating to Azure Database for MySQL Flexible Server at the earliest. Post the sunset date, your Single Server instance, along with its data files, will be [force-migrated](./whats-happening-to-mysql-single-server.md#forced-migration-post-sunset-date) to an appropriate Flexible Server instance in a phased manner.
 
 **Q. Can I choose to continue running Single Server beyond the sunset date?**
 
 **A.** Unfortunately, we don't plan to support Single Server beyond the sunset date of **September 16, 2024**, and hence we strongly advise that you start planning your migration as soon as possible. Post the sunset date, your Single Server instance, along with its data files, will be force-migrated to an appropriate Flexible Server instance in a phased manner. This might lead to limited feature availability as certain advanced functionality can't be force-migrated without customer inputs to the Flexible Server instance. Read more about steps to reconfigure such features post force-migration to minimize the potential impact [here](./whats-happening-to-mysql-single-server.md#action-required-post-forced-migration). If your server is in a region where Azure Database for MySQL - Flexible Server isn't supported, then post the sunset date, your Single Server instance is available with limited operations to access data and to be able to migrate to Flexible Server.
 
 **Q. My single server is deployed in a region that doesn't support flexible server. What will happen to my server post sunset date?**
+
 **A.** If your server is in a region where Azure Database for MySQL - Flexible Server isn't supported, then post the sunset date, your Single Server instance is available with limited operations to access data and to be able to migrate to Flexible Server. We strongly recommend that you use one of the following options to migrate before the sunset date to avoid any disruptions in business continuity:
 
 - Use Azure DMS to perform a cross-region migration to Flexible Server in a suitable Azure region.
 - Migrate to MySQL Server hosted on a VM in the region, if you're unable to change regions due to compliance issues.
 
 **Q. Post sunset date, will there be any data loss for my Single Server?**
+
 **A.** No, there won't be any data loss incurred for your Single Server instance. Post the sunset date, your Single Server instance, along with its data files, will be force-migrated to an appropriate Flexible Server instance. If your server is in a region where Azure Database for MySQL - Flexible Server isn't supported, then post the sunset date, your Single Server instance is available with limited operations to access data and to be able to migrate to Flexible Server in an appropriate region.
 
 **Q. After the Single Server retirement announcement, what if I still need to create a new single server to meet my business needs?**
@@ -239,3 +241,5 @@ We know migrating services can be a frustrating experience, and we apologize in
 - [Frequently Asked Questions about DMS (classic) migrations](../../dms/faq-mysql-single-to-flex.md)
 - [Select the right tools for migration to Azure Database for MySQL](../migrate/how-to-decide-on-right-migration-tools.md)
 - [What is Flexible Server](../flexible-server/overview.md)
+
+