Merge pull request #223302 from VandhanaMehta/doccorrections

prmerger-automator[bot] · web-flow · commit 35ba96c4aeb4 · 2023-01-09T11:04:55.000Z
making some corrections in the existing doc content
diff --git a/articles/mysql/flexible-server/concepts-data-in-replication.md b/articles/mysql/flexible-server/concepts-data-in-replication.md
@@ -45,7 +45,7 @@ It isn't supported to configure Data-in replication for servers that have high a
 
 ### Filter
 
-Modifying the parameter `replicate_wild_ignore_table` used to create replication filter for tables is currently not supported for Azure Database for MySQL -Flexible server.
+Parameter `replicate_wild_ignore_table` is used to create replication filter for tables on the replica server. To modify this parameter from Azure portal, navigate to Azure Database for MySQL - Flexible Server used as replica and select "Server Parameters" to view/edit the `replicate_wild_ignore_table` parameter.
 
 ### Requirements
 
diff --git a/articles/mysql/flexible-server/how-to-data-out-replication.md b/articles/mysql/flexible-server/how-to-data-out-replication.md
@@ -146,7 +146,7 @@ Restore the dump file to the server created in the Azure Database for MySQL Flex
 
 1. Filtering
 
-   Suppose data-out replication is being set up between Azure MySQL and an external MySQL on other cloud providers or on-premises. In that case, you must use the replication filter to filter out Azure custom tables. This can be achieved by setting Replicate_Wild_Ignore_Table = "mysql.\_\_%" to filter the Azure mysql internal tables. To modify this parameter from the Azure portal, navigate to Azure Database for MySQL Flexible server used as source and select "Server parameters" to view/edit the "Replicate_Wild_Ignore_Table" parameter. Refer to [MySQL :: MySQL 5.7 Reference Manual :: 13.4.2.2 CHANGE REPLICATION FILTER Statement](https://dev.mysql.com/doc/refman/5.7/en/change-replication-filter.html) for more details on modifying this server parameter.
+   Suppose data-out replication is being set up between Azure MySQL and an external MySQL on other cloud providers or on-premises. In that case, you must use the replication filter to filter out Azure custom tables on the replica server. This can be achieved by setting Replicate_Wild_Ignore_Table = "mysql.\_\_%" to filter the Azure mysql internal tables. Refer to [MySQL :: MySQL 5.7 Reference Manual :: 13.4.2.2 CHANGE REPLICATION FILTER Statement](https://dev.mysql.com/doc/refman/5.7/en/change-replication-filter.html) for more details on modifying this server parameter.
 
 1. Set the replica server by connecting to it and opening the MySQL shell on the replica server. From the prompt, run the following operation, which configures several MySQL replication settings at the same time:
 
diff --git a/articles/mysql/single-server/concepts-backup.md b/articles/mysql/single-server/concepts-backup.md
@@ -81,7 +81,7 @@ The primary means of controlling the backup storage cost is by setting the appro
 
 ## Restore
 
-In Azure Database for MySQL, performing a restore creates a new server from the original server's backups and restores all databases contained in the server.
+In Azure Database for MySQL, performing a restore creates a new server from the original server's backups and restores all databases contained in the server. Restore is currently not supported if original server is in stopped state.
 
 There are two types of restore available:
 
diff --git a/articles/mysql/single-server/concepts-pricing-tiers.md b/articles/mysql/single-server/concepts-pricing-tiers.md
@@ -58,7 +58,7 @@ Azure Database for MySQL – Single Server supports the following the backend st
 > Basic storage does not provide an IOPS guarantee. In General Purpose storage, the IOPS scale with the provisioned storage size in a 3:1 ratio.
 
 ### Basic storage 
-Basic storage is the backend storage supporting Basic pricing tier servers. Basic storage leverages Azure standard storage in the backend where iops provisioned are not guaranteed and latency is variable. Basic tier is best suited for workloads that require light compute, low cost and I/O performance for development or small-scale infrequently used applications.
+Basic storage is the backend storage supporting Basic pricing tier servers. Basic storage uses Azure standard storage in the backend where iops provisioned are not guaranteed and latency is variable. Basic tier is best suited for workloads that require light compute, low cost and I/O performance for development or small-scale infrequently used applications.
 
 ### General purpose storage 
 General purpose storage is the backend storage supporting General Purpose and Memory Optimized tier server. In General Purpose storage, the IOPS scale with the provisioned storage size in a 3:1 ratio. There are two generations of general purpose storage as described below:
@@ -104,7 +104,7 @@ General purpose storage v2 is supported in the following Azure regions:
 | West US | :heavy_check_mark: | 
 | West US 2 | :heavy_check_mark: | 
 | West Europe | :heavy_check_mark: | 
-| Central India* | :heavy_check_mark: | 
+| Central India | :heavy_check_mark: | 
 | France Central* | :heavy_check_mark: | 
 | UAE North* | :heavy_check_mark: | 
 | South Africa North* | :heavy_check_mark: |
