Merge pull request #177358 from aditivgupta/frp

Changes for Available Backups/Fastest Restore Point/Server Parameters

Author: ttorble

articles/mysql/flexible-server/concepts-backup-restore.md

@@ -65,6 +65,10 @@ The primary means of controlling the backup storage cost is by setting the appro
 > [!IMPORTANT]
 > Backups from a database server configured in a zone redundant high availability configuration happens from the primary database server as the overhead is minimal with snapshot backups.
 
+## View Available Full Backups
+
+The Backup and Restore blade in the Azure portal lists the automated full backups taken daily once. One can use this blade to view the completion timestamps for all available full backups within the server’s retention period and to perform restore operations using these full backups. The list of available backups includes all full automated backups within the retention period, a timestamp showing the successful completion, a timestamp indicating how long a backup will be retained, and a restore action.
+
 ## Restore
 
 In Azure Database for MySQL, performing a restore creates a new server from the original server's backups. There are two types of restore available: 
@@ -99,10 +103,11 @@ Point-in-time restore is useful in multiple scenarios. Some of the use cases tha
 -   User drops an important table or database
 -   User application accidentally overwrites good data with bad data due to an application defect.
 
-You can choose between a latest restore point and a custom restore point via [Azure portal](how-to-restore-server-portal.md).
+You can choose between latest restore point, custom restore point and fastest restore point (restore using full backup) via [Azure portal](how-to-restore-server-portal.md).
 
 -   **Latest restore point**: The latest restore point option helps you to restore the server to the timestamp when the restore operation was triggered. This option is useful to quickly restore the server to the most updated state.
 -   **Custom restore point**: This will allow you to choose any point-in-time within the retention period defined for this flexible server. This option is useful to restore the server at the precise point in time to recover from a user error.
+-   **Fastest restore point**: This option allows users to restore the server in the fastest time possible for a given day within the retention period defined for their flexible server. Fastest restore is possible by choosing the restore point-in-time at which the full backup is completed. This restore operation simply restores the full snapshot backup and doesn't warrant restore or recovery of logs which makes it fast. We recommend you select a full backup timestamp which is greater than the earliest restore point in time for a successful restore operation.
 
 The estimated time of recovery depends on several factors including the database sizes, the transaction log backup size, the compute size of the SKU, and the time of the restore as well. The transaction log recovery is the most time consuming part of the restore process. If the restore time is chosen closer to the snapshot backup schedule, the restore operations are faster since transaction log application is minimal. To estimate the accurate recovery time for your server, we highly recommend testing it in your environment as it has too many environment specific variables.
 
@@ -167,7 +172,7 @@ No, backups are triggered internally as part of the managed service and have no
 Azure Database for MySQL automatically creates server backups and stores them in user-configured, locally redundant storage or in geo-redundant storage. These backup files can't be exported. The default backup retention period is seven days. You can optionally configure the database backup from 1 to 35 days.
 
 - **How can I validate my backups?**
-The best way to validate availability of valid backups is performing periodic point in time restores and ensuring backups are valid and restorable. Backup operations or files are not exposed to the end users.
+The best way to validate availability of successfully completed backups is to view the full automated backups taken within the retention period in the Backup and Restore blade. If a backup fails it will not be listed in the available backups list and our backup service will try every 20 mins to take a backup until a successful backup is taken. These backup failures are due to heavy transactional production loads on the server.
 
 - **Where can I see the backup usage?**
 In the Azure portal, under Monitoring tab - Metrics section, you can find the [Backup Storage Used](./concepts-monitoring.md) metric which can help you monitor the total backup usage.

articles/mysql/flexible-server/concepts-limitations.md

@@ -63,7 +63,6 @@ The following are unsupported:
 - Connectivity method cannot be changed after creating the server. If the server is created with *Private access (VNet Integration)*, it cannot be changed to *Public access (allowed IP addresses)* after create, and vice versa
 
 ### Stop/start operation
-- Not supported with zone redundant HA configurations (both primary and standby).
 - Not supported with read replica configurations (both source and replicas).
 
 ### Scale operations

articles/mysql/flexible-server/concepts-read-replicas.md

@@ -108,7 +108,7 @@ After your application is successfully processing reads and writes, you have com
 
 ## Global transaction identifier (GTID)
 
-Global transaction identifier (GTID) is a unique identifier created with each committed transaction on a source server and is OFF by default in Azure Database for MySQL Flexible serever. GTID is supported on versions 5.7 and 8.0. To learn more about GTID and how it's used in replication, refer to MySQL's [replication with GTID](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html) documentation.
+Global transaction identifier (GTID) is a unique identifier created with each committed transaction on a source server and is OFF by default in Azure Database for MySQL Flexible server. GTID is supported on versions 5.7 and 8.0. To learn more about GTID and how it's used in replication, refer to MySQL's [replication with GTID](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html) documentation.
 
 The following server parameters are available for configuring GTID:
 

articles/mysql/flexible-server/concepts-server-parameters.md

@@ -68,6 +68,15 @@ MySQL stores the InnoDB table in different tablespaces based on the configuratio
 
 Azure Database for MySQL Flexible Server supports at largest, **4 TB**, in a single data file. If your database size is larger than 4 TB, you should create the table in [innodb_file_per_table](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_file_per_table) tablespace. If you have a single table size larger than 4 TB, you should use the partition table.
 
+### innodb_log_file_size
+
+[innodb_log_file_size](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_log_file_size) is the size in bytes of each [log file](https://dev.mysql.com/doc/refman/8.0/en/glossary.html#glos_log_file) in a [log group](https://dev.mysql.com/doc/refman/8.0/en/glossary.html#glos_log_group). The combined size of log files [(innodb_log_file_size](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_log_file_size) * [innodb_log_files_in_group](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_log_files_in_group)) cannot exceed a maximum value that is slightly less than 512GB). A bigger log file size is better for performance, but it has a drawback that the recovery time after a crash will be high. You need to balance recovery time in the rare event of a crash recovery versus maximizing throughput during peak operations. These can also result in longer restart times. You can configure innodb_log_size to any of these values - 256MB, 512MB, 1GB or 2GB for Azure database for MySQL Flexible server. The parameter is static and requires a restart.
+
+> [!NOTE]
+> If you have changed the parameter innodb_log_file_size from default, check if the value of "show global status like 'innodb_buffer_pool_pages_dirty'" stays at 0 for 30 seconds to avoid restart delay.
+
+
+
 ### max_connections
 
 The value of max_connection is determined by the memory size of the server.

articles/mysql/flexible-server/connect-azure-cli.md

@@ -21,10 +21,10 @@ This quickstart demonstrates how to connect to an Azure Database for MySQL Flexi
 
     [!INCLUDE [flexible-server-free-trial-note](../includes/flexible-server-free-trial-note.md)]
 - Install [Azure CLI](/cli/azure/install-azure-cli) latest version (2.20.0 or above)
-- Login using Azure CLI with ```az login``` command
+- Log in using Azure CLI with ```az login``` command
 - Turn on parameter persistence with ```az config param-persist on```. Parameter persistence will help you use local context without having to repeat a lot of arguments like resource group or location etc.
 
-## Create an MySQL Flexible Server
+## Create a MySQL Flexible Server
 
 The first thing we'll create is a managed MySQL server. In [Azure Cloud Shell](https://shell.azure.com/), run the following script and make a note of the **server name**, **username** and  **password** generated from this command.
 
@@ -69,9 +69,9 @@ Successfully connected to mysqldemoserver1.
 ```
 If the connection failed, try these solutions:
 - Check if port 3306 is open on your client machine.
-- if your server administrator user name and password are correct
-- if you have configured firewall rule for your client machine
-- if you have configured your server with private access in virtual networking, make sure your client machine is in the same virtual network.
+- If your server administrator user name and password are correct
+- If you have configured firewall rule for your client machine
+- If you have configured your server with private access in virtual networking, make sure your client machine is in the same virtual network.
 
 ## Run multiple queries using interactive mode
 You can run multiple queries using the **interactive** mode. To enable interactive mode, run the following command

articles/mysql/flexible-server/how-to-read-replicas-cli.md

@@ -5,7 +5,7 @@ author: savjani
 ms.author: pariks
 ms.service: mysql
 ms.topic: how-to
-ms.date: 10/23/2020
+ms.date: 10/23/2021
 ms.custom: devx-track-azurecli
 ---
 

articles/mysql/flexible-server/how-to-restore-server-portal.md

@@ -42,6 +42,54 @@ Follow these steps to restore your flexible server using an earliest existing ba
 
 8. A notification will be shown that the restore operation has been initiated.
 
+
+## Restore to a fastest restore point
+
+Follow these steps to restore your flexible server using an existing full backup as the fastest restore point. 
+
+1. In the [Azure portal](https://portal.azure.com/), choose your flexible server that you want to restore the backup from. 
+
+2. Click **Overview** from the left panel. 
+
+3. From the overview page, click **Restore**. 
+
+4. Restore page will be shown with an option to choose between Latest restore point, Custom restore point and Fastest Restore Point. 
+
+5. Select option **Select fastest restore point (Restore using full backup)**. 
+
+6. Select the desired full backup from the **Fastest Restore Point (UTC)** drop down list . 
+ 
+    :::image type="content" source="./media/how-to-restore-server-portal/fastest-restore-point.png" alt-text="Fastest Restore Point":::
+
+7. Provide a new server name in the **Restore to new server** field.
+
+8. Click **Review + Create**. 
+
+9. Post clicking **Create**, a notification will be shown that the restore operation has been initiated.  
+
+## Restore from a full backup through the Backup and Restore blade
+
+Follow these steps to restore your flexible server using an existing full backup. 
+
+1. In the [Azure portal](https://portal.azure.com/), choose your flexible server that you want to restore the backup from. 
+
+2. Click **Backup and Restore** from the left panel. 
+
+3. View Available Backups page will be shown with the option to restore from all full automated backups taken for the server within the retention period.  
+
+4. Select the desired full backup from the list by clicking on corresponding **Restore** action. 
+ 
+    :::image type="content" source="./media/how-to-restore-server-portal/view-available-backups.png" alt-text="View Available Backups":::
+
+5. Restore page will be shown with the Fastest Restore Point option selected by default and the desired full backup timestamp selected on the View Available backups page. 
+
+6. Provide a new server name in the **Restore to new server** field.
+
+7. Click **Review + Create**. 
+
+8. Post clicking **Create**, a notification will be shown that the restore operation has been initiated.  
+
+
 ## Geo-restore to latest restore point
 
 1. In the [Azure portal](https://portal.azure.com/), choose your flexible server that you want to restore the backup from.

articles/mysql/flexible-server/media/how-to-restore-server-portal/fastest-restore-point.png

@@ -12,7 +12,7 @@ ms.custom: mvc, devx-track-azurecli
 
 # Quickstart: Create an Azure Database for MySQL Flexible Server using Azure CLI
 
-[[!INCLUDE[applies-to-mysql-flexible-server](../includes/applies-to-mysql-flexible-server.md)]
+[!INCLUDE[applies-to-mysql-flexible-server](../includes/applies-to-mysql-flexible-server.md)]
 
 
 This quickstart shows how to use the [Azure CLI](/cli/azure/get-started-with-azure-cli) commands in [Azure Cloud Shell](https://shell.azure.com) to create an Azure Database for MySQL Flexible Server in five minutes.