Add

Author: aditiiitb

articles/dms/migrate-azure-mysql-consistent-backup.md

@@ -1,6 +1,6 @@
 ---
 title: MySQL to Azure Database for MySQL Data Migration - MySQL Consistent Backup
-description: Learn how to use the Azure Database for MySQL Data Migration - MySQL Consistent Backup for transaction consistency even without making the Source server read-only
+description: Learn how to use the Azure Database for MySQL Data Migration - MySQL Consistent Backup for transaction consistency even without making the Source server read-only.
 author: karlaescobar
 ms.author: karlaescobar
 ms.date: 04/19/2022
@@ -19,45 +19,45 @@ MySQL Consistent Snapshot is a new feature that allows users to take a Consisten
 
 ## Enable Consistent Snapshot without locks (Preview)
 
-When you enable this option, a reconciliation phase will occur after initial load to ensure that teh data written to your target will be transactionally consistent with the source server from a specific position in the binary log.
+When you enable this option, a reconciliation phase will occur after the initial load. This is to ensure that the data written to your target is transactionally consistent with the source server from a specific position in the binary log.
 
-With this feature, we do not take a read lock on the server and instead read tables at different point in time, while keeping track of the tables' binlog positions to be able to reconcile them towards the end of the initial load by performing replication in catchup mode to get a consistent snapshot.
+With this feature, we don't take a read lock on the server. We instead read tables at different point in time, while keeping track of the different binlog positions of each table. This aids to reconcile the tables towards the end of the initial load by performing replication in catchup mode to get a consistent snapshot.
 
 :::image type="content" source="media/migrate-azure-mysql-consistent-backup/reconciliation.png" alt-text="MySQL to Azure Database for MySQL Data Migration Wizard - Reconciliation progress" lightbox="media/migrate-azure-mysql-consistent-backup/reconciliation.png":::
 
-Key features of Consistent Snapshot without locks :
+Key features of Consistent Snapshot without locks:
     *Ability to support heavy workload servers or servers with long-running transactions without the need for read locks.
-    *Resilient in completing migrations even in the event of failures caused by transient network/server blips that result in loss of all the pre-created connections.
-    *Ability to resume migrations upon DMS agent upgrades or restarts.
+    *Resilient in completing migrations even in the event of failures caused by transient network/server blips that result in loss of all the precreated connections.
+    *Ability to resume migrations upon Data Migration Service (DMS) agent upgrades or restarts.
 
 ### Enable Consistent Snapshot with read lock (GA)
 
-When you enable this option, the service flushes all tables on the source server with a **read** lock to obtain the point-in-time snapshot. This flushing is done because a global lock is more reliable than attempting to lock individual databases or tables. As a result, even if you are not migrating all databases in a server, they are locked as part of setting up the migration process. The migration service initiates a repeatable read and combines the current table state with contents of the undo log for the snapshot. The **snapshot** is generated after obtaining the server wide lock and spawning several connections for the migration. After the creation of all connections used for the migration, the locks on the table are released.
+When you enable this option, the service flushes all tables on the source server with a **read** lock to obtain the point-in-time snapshot. This flushing is done because a global lock is more reliable than attempting to lock individual databases or tables. As a result, even if you aren't migrating all databases in a server, they're locked as part of setting up the migration process. The migration service initiates a repeatable read and combines the current table state with contents of the undo log for the snapshot. The **snapshot** is generated after obtaining the server wide lock and spawning several connections for the migration. After the creation of all connections used for the migration, the locks on the table are released.
 
-Repeatable reads are enabled to keep the undo logs accessible during the migration, which increase the storage required on the source because of long running connections. A long running migration with multiple table changes leads to an extensive undo log history that needs to be replayed and could also increase the compute requirements and load on the source server.
+Repeatable reads are enabled to keep the undo logs accessible during the migration, which increases the storage required on the source because of long running connections. A long running migration with multiple table changes leads to an extensive undo log history that needs to be replayed and could also increase the compute requirements and load on the source server.
 
 ### Make the Source Server Read Only
 
- Selecting this option maintains the data integrity of the target database as the source is migrated by preventing Write/Delete operations on the source server during migration. When you make the source server read only as part of the migration process, the selection applies to all the source server’s databases, regardless of whether they are selected for migration.
+ Selecting this option maintains the data integrity of the target database as the source is migrated by preventing Write/Delete operations on the source server during migration. When you make the source server read only as part of the migration process, the selection applies to all the source server’s databases, regardless of whether they're selected for migration.
 
-Making the source server read only prevents users from modifying the data, rendering the database unavailable for any update operations. However, if this option is not enabled, there is a possibility for data updates to occur during migration. As a result, migrated data could be inconsistent because the database snapshots would be read at different points in time.
+Making the source server read only prevents users from modifying the data, rendering the database unavailable for any update operations. However, if this option isn't enabled, there is a possibility for data updates to occur during migration. As a result, migrated data could be inconsistent because the database snapshots would be read at different points in time.
 
 ## Prerequisites for Enable Consistent Snapshot with read lock
 
-To complete the migration successfully with Consistent Snapshot with read lock enabled :
+To complete the migration successfully with Consistent Snapshot with read lock enabled:
 
 - Ensure that the user who is attempting to flush tables with a **read lock** has the RELOAD or FLUSH permission.
 
-- Use the mysql client tool to determine whether log_bin is enabled on the source server. The Bin log is not always turned on by default and should be checked to see if it is enabled before starting the migration. The mysql client tool is used to determine whether **log_bin** is enabled on the source by running the command: **SHOW VARIABLES LIKE 'log_bin';**
+- Use the mysql client tool to determine whether log_bin is enabled on the source server. The Bin log isn't always turned on by default and should be checked to see if it is enabled before starting the migration. The mysql client tool is used to determine whether **log_bin** is enabled on the source by running the command: **SHOW VARIABLES LIKE 'log_bin';**
 
 > [!NOTE]
 > With Azure Database for MySQL Single Server, which supports up to 4TB, this is not enabled by default. However, if you promote a read replica for the source server and then delete read replica, the parameter is set to ON.
 
-- Configure the **binlog_expire_logs_seconds** parameter on the source server to ensure that binlog files are not purged before the replica commits the changes. Post successful cutover, the value can be reset.
+- Configure the **binlog_expire_logs_seconds** parameter on the source server to ensure that binlog files are'nt purged before the replica commits the changes. Post successful cutover, the value can be reset.
 
 ## Known issues and limitations for Enable Consistent Snapshot without locks
 
-- Tables with foreign keys having Cascade or Set Null on delete/on update clause are not supported.
+- Tables with foreign keys having Cascade or Set Null on delete/on update clause aren't supported.
 
 ## Known issues and limitations for Enable Consistent Snapshot with read lock
 
@@ -68,17 +68,17 @@ The known issues and limitations associated with Consistent Backup fall broadly
 
 ### Locks
 
-Typically, it is a straightforward process to obtain a lock, which should take between a few seconds and a couple of minutes to complete. In a few scenarios, however, attempts to obtain a lock on the source server can fail.
+Typically, it's a straightforward process to obtain a lock, which should take between a few seconds and a couple of minutes to complete. In a few scenarios, however, attempts to obtain a lock on the source server can fail.
 
 - The presence of long running queries could result in unnecessary downtime, as DMS could lock a subset of the tables and then time out waiting for the last few to come available. Before starting the migration, check for any long running operations by running the **SHOW PROCESSLIST** command.  
 
-- If the source server is experiencing a lot of write updates at the time a lock is requested, the lock cannot be readily obtained and could fail after the lock-wait timeout. This happens in the case of batch processing tasks in the tables, which when in progress may result in denying the request for a lock. As mentioned earlier, the lock requested is a single global-level lock for the entire server so even if a single table or database is under processing, the lock request would have to wait for the ongoing task to conclude.  
+- If the source server is experiencing many write updates at the time a lock is requested, the lock cannot be readily obtained and could fail after the lock-wait timeout. This happens in the case of batch processing tasks in the tables, which when in progress may result in denying the request for a lock. As mentioned earlier, the lock requested is a single global-level lock for the entire server so even if a single table or database is under processing, the lock request would have to wait for the ongoing task to conclude.  
 
-- Another limitation relates to migrating from an RDS source server. RDS does not support flush tables with read lock and **LOCK TABLE** query is run on the selected tables under the hood. As the tables are locked individually, the locking process can be less reliable, and locks can take longer to acquire.
+- Another limitation relates to migrating from an AWS RDS source server. RDS does not support flush tables with read lock and **LOCK TABLE** query is run on the selected tables under the hood. As the tables are locked individually, the locking process can be less reliable, and locks can take longer to acquire.
 
 ### Retries
 
-The migration handles transient connection issues and additional connections are typically provisioned upfront for this purpose. We look at the migration settings, particularly the number of parallel read operations on the source and apply a factor (typically ~1.5) and create as many connections up-front. This way the service makes sure we can keep operations running in parallel. At any point of time, if there is a connection loss or the service is unable to obtain a lock, the service uses the surplus connections provisioned to retry the migration. If all the provisioned connections are exhausted resulting in the loss of the point-in-time sync , the migration must be restarted from the beginning. In cases of both success and failure, all cleanup actions are undertaken by this offline migration service and the user does not have to perform any explicit cleanup actions.
+The migration handles transient connection issues and additional connections are typically provisioned upfront for this purpose. We look at the migration settings, particularly the number of parallel read operations on the source and apply a factor (typically ~1.5) and create as many connections up-front. This way the service makes sure we can keep operations running in parallel. At any point of time, if there is a connection loss or the service is unable to obtain a lock, the service uses the surplus connections provisioned to retry the migration. If all the provisioned connections are exhausted resulting in the loss of the point-in-time sync, the migration must be restarted from the beginning. In cases of both success and failure, all cleanup actions are undertaken by this offline migration service and the user does not have to perform any explicit cleanup actions.
 
 ## Next steps