Merge pull request #249672 from aditivgupta/dmsissues

Dmsissues

Author: prmerger-automator[bot]

articles/dms/concepts-migrate-azure-mysql-replicate-changes.md

@@ -25,13 +25,14 @@ You must run an offline migration scenario with "Enable Transactional Consistenc
 
 While running the replicate changes migration, when your target is almost caught up with the source server, stop all incoming transactions to the source database and wait until all pending transactions have been applied to the target database. To confirm that the target database is up-to-date on the source server, run the query 'SHOW MASTER STATUS;', then compare that position to the last committed binlog event (displayed under Migration Progress). When the two positions are the same, the target has caught up with all changes, and you can start the cutover.
 
+
 ### How Replicate Changes works
 
 The current implementation is based on streaming binlog changes from the source server and applying them to the target server. Like Data-in replication, this is easier to set up and doesn't require a physical connection between the source and the target servers.
 
 The server can send Binlog as a stream that contains binary data as documented [here](https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_replication.html). The client can specify the initial log position to start the stream with. The log file name describes the log position, the position within that file, and optionally GTID (Global Transaction ID) if gtid mode is enabled at the source.
 
-The data changes are sent as "row" events, which contain data for individual rows (prior and/or after the change depending on the operation type, which is insert, delete, or update). The row events are then applied in their raw format using a BINLOG statement: [MySQL 8.0 Reference Manual :: 13.7.8.1 BINLOG Statement](https://dev.mysql.com/doc/refman/8.0/en/binlog.html).
+The data changes are sent as "row" events, which contain data for individual rows (prior and/or after the change depending on the operation type, which is insert, delete, or update). The row events are then applied in their raw format using a BINLOG statement: [MySQL 8.0 Reference Manual :: 13.7.8.1 BINLOG Statement](https://dev.mysql.com/doc/refman/8.0/en/binlog.html). But for a DMS migration to a 5.7 server, DMS doesn’t apply changes as BINLOG statements (since DMS doesn’t have necessary privileges to do so) and instead translates the row events into INSERT, UPDATE, or DELETE statements.
 
 ## Prerequisites
 
@@ -49,6 +50,7 @@ To complete the replicate changes migration successfully, ensure that the follow
 - When performing a replicate changes migration, the name of the database on the target server must be the same as the name on the source server.
 - Support is limited to the ROW binlog format.
 - DDL changes replication is supported only when you have selected the option for migrating entire server on DMS UI.
+- Renaming databases or tables is not supported when replicating changes.
 
 ## Next steps
 

articles/dms/known-issues-azure-mysql-fs-online.md

@@ -94,17 +94,17 @@ One or more incompatible SQL modes can cause many different errors. Below is an
 
 - **Error**: An error occurred as referencing table cannot be found.
 
-  **Potential error message**: The pipeline was unable to create the schema of object '{object}' for activity '{activity}' using strategy MySqlSchemaMigrationViewUsingTableStrategy because of a query execution.   
+  **Potential error message**: The pipeline was unable to create the schema of object '{object}' for activity '{activity}' using strategy MySqlSchemaMigrationViewUsingTableStrategy because of a query execution.
 
-  **Limitation**: The error can occur when the view is referring to a table that has been deleted or renamed, or when the view was created with incorrect or incomplete information.
+  **Limitation**: The error can occur when the view is referring to a table that has been deleted or renamed, or when the view was created with incorrect or incomplete information. This error can happen if a subset of tables are migrated, but the tables they depend on are not.
 
-  **Workaround**: We recommend migrating views manually.
+  **Workaround**: We recommend migrating views manually. Check if all tables referenced in foreign keys and CREATE VIEW statements are selected for migration.
 
 ## All pooled connections broken
 
 - **Error**: All connections on the source server were broken.  
 
-  **Limitation**: The error occurs when all the connections that are acquired at the start of initial load are lost due to server restart, network issues, heavy traffic on the source server or other transient problems. This error isn't recoverable. 
+  **Limitation**: The error occurs when all the connections that are acquired at the start of initial load are lost due to server restart, network issues, heavy traffic on the source server or other transient problems. This error isn't recoverable. Additionally, this error occurs if an attempt to migrate a server is made during the maintenance window.
 
   **Workaround**: The migration must be restarted, and we recommend increasing the performance of the source server. Another issue is scripts that kill long running connections, prevents these scripts from working.
 

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

@@ -13,16 +13,16 @@ ms.custom: mvc, mode-api
 
 [!INCLUDE[applies-to-mysql-single-server](../includes/applies-to-mysql-single-server.md)]
 
-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 or General Purpose SKU, data storage used < 10 GiB and no complex features enabled. The eligible servers are identified by the service and are sent an advance notification detailing steps to review migration details.
+**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 or General Purpose SKU**, data storage used **< 10 GiB** and **no complex features (CMK, AAD, Read Replica, Private Link) enabled**. The eligible servers are identified by the service and are sent an advance notification detailing steps to review migration details.
 
-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:
+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 post days set as it's Backup Retention Period.
+* **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 post days set as it's Backup Retention Period.
 
 > [!NOTE]
-> In-place migration is only for Single Server database workloads with Basic or GP SKU, data storage used < 10 GiB and no complex features enabled. All other Single Server workloads are recommended to use user-initiated migration tooling offered by Azure - Azure DMS, Azure MySQL Import to migrate.
+> In-place migration is only for Single Server database workloads with Basic or GP SKU, data storage used < 10 GiB and no complex features (CMK, AAD, Read Replica, Private Link) enabled. All other Single Server workloads are recommended to use user-initiated migration tooling offered by Azure - Azure DMS, Azure MySQL Import to migrate.
 
 ## Configure migration alerts and review migration schedule
 
@@ -31,23 +31,23 @@ Servers eligible for in-place automigration are sent an advance notification by
 Following described are the ways to check and configure automigration notifications:
 
 * Subscription owners for Single Servers scheduled for automigration receive an email notification.
-* Configure service health alerts to receive in-place migration schedule and progress notifications via email/SMS by following steps [here](../single-server/concepts-planned-maintenance-notification.md#to-receive-planned-maintenance-notification).
-* Check the in-place migration notification on the Azure portal by following steps [here](../single-server/concepts-planned-maintenance-notification.md#check-planned-maintenance-notification-from-azure-portal).
+* Configure **service health alerts** to receive in-place migration schedule and progress notifications via email/SMS by following steps [here](../single-server/concepts-planned-maintenance-notification.md#to-receive-planned-maintenance-notification).
+* Check the in-place migration **notification on the Azure portal** by following steps [here](../single-server/concepts-planned-maintenance-notification.md#check-planned-maintenance-notification-from-azure-portal).
 
 Following described are the ways to review your migration schedule once you have received 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 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.
+* The S**ingle 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 **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.
 
 ## Pre-requisite checks for in-place auto-migration
 
-* The Single Server instance should be in ready state and should not be in stopped state during the planned maintenance window for automigration to take place.
-* For Single Server instance with SSL enabled, ensure you have both certificates (BaltimoreCyberTrustRoot & DigiCertGlobalRootG2 Root CA) available in the trusted root store. Additionally, if you have the certificate pinned to the connection string create a combined CA certificate before scheduled auto-migration by following steps [here](../single-server/concepts-certificate-rotation.md#create-a-combined-ca-certificate) to ensure business continuity post-migration.
+* The Single Server instance should be in **ready state** and should not be in stopped state during the planned maintenance window for automigration to take place.
+* For Single Server instance with **SSL enabled**, ensure you have both certificates (**BaltimoreCyberTrustRoot & DigiCertGlobalRootG2 Root CA**) available in the trusted root store. Additionally, if you have the certificate pinned to the connection string create a combined CA certificate before scheduled auto-migration by following steps [here](../single-server/concepts-certificate-rotation.md#create-a-combined-ca-certificate) to ensure business continuity post-migration.
 * The MySQL engine doesn't guarantee any sort order if there is no 'SORT' clause present in queries. Post in-place automigration, you may observe a change in the sort order. If preserving sort order is crucial, ensure your queries are updated to include 'SORT' clause before the scheduled in-place automigration.
 
 ## How is the target MySQL Flexible Server auto-provisioned?
@@ -69,7 +69,7 @@ Following described are the ways to review your migration schedule once you have
     | Memory Optimized | 32 | MemoryOptimized | Standard_E32ds_v4 |
 
 * The MySQL version, region, *storage size, subscription and resource group for the target Flexible Server is same as that of the source Single Server.
-*For Single Servers with less than 20 GiB storage, the storage size is set to 20 GiB as that is the minimum storage limit on Azure Database for MySQL - Flexible Server.
+* For Single Servers with less than 20 GiB storage, the storage size is set to 20 GiB as that is the minimum storage limit on Azure Database for MySQL - Flexible Server.
 * Both username formats – username@server_name (Single Server) and username (Flexible Server) are supported on the migrated Flexible Server.
 * Both connection string formats – Single Server and Flexible Server are supported on the migrated Flexible Server.
 
@@ -95,7 +95,7 @@ Copy the following properties from the source Single Server to target Flexible S
 
 **Q. How can I set up or view in-place migration alerts?​**
 
-**A.**
+**A.** Following are the ways you can set up alerts :
 
 * Configure service health alerts to receive in-place migration schedule and progress notifications via email/SMS by following steps [here](../single-server/concepts-planned-maintenance-notification.md#to-receive-planned-maintenance-notification).
 * Check the in-place migration notification on the Azure portal by following steps [here](../single-server/concepts-planned-maintenance-notification.md#check-planned-maintenance-notification-from-azure-portal).
@@ -106,7 +106,7 @@ Copy the following properties from the source Single Server to target Flexible S
 
 **Q. What are some post-migration activities I need to perform?​**
 
-**A.**
+**A.** Following are some post-migration activities :
 
 * Monitoring page settings (Alerts, Metrics, and Diagnostic settings)
 * Any Terraform/CLI scripts you host to manage your Single Server instance should be updated with Flexible Server references.

articles/mysql/migrate/migrate-single-flexible-mysql-import-cli.md

@@ -158,6 +158,7 @@ iops | 500 | Number of IOPS to be allocated for the target Azure Database for My
 ## How long does MySQL Import take to migrate my Single Server instance?
 
 Below is the benchmarked performance based on storage size.
+
   | Single Server Storage Size | MySQL Import time |
   | ------------- |:-------------:|
   | 1 GiB | 0 min 23 secs |
@@ -170,8 +171,9 @@ Below is the benchmarked performance based on storage size.
 From the table above, as the storage size increases, the time required for data copying also increases, almost in a linear relationship. However, it's important to note that copy speed can be significantly impacted by network fluctuations. Therefore, the data provided here should be taken as a reference only.
 
 Below is the benchmarked performance based on varying number of tables for 10 GiB storage size.
+
   | Number of tables in Single Server instance | MySQL Import time |
-  | ------------- |:-------------:|
+  | ------------- | :-------------: |
   | 100 | 4 min 24 secs |
   | 200 | 4 min 40 secs |
   | 800 | 4 min 52 secs |