+The `Billing` setting specifies the endpoint URI of the _Azure AI services_ resource on Azure used to meter billing information for the container. You must specify a value for this configuration setting, and the value must be a valid endpoint URI for an _Azure AI services_ resource on Azure. The container reports usage about every 10 to 15 minutes.

+You must create a `PronunciationAssessmentConfig` object. Optionally you can set `EnableProsodyAssessment` and `EnableContentAssessmentWithTopic` to enable prosody and content assessment. For more information, see [configuration methods](#configuration-methods).

+### Configuration methods

+This table lists some of the optional methods you can set for the `PronunciationAssessmentConfig` object.

+> [!NOTE]

+> Content and prosody assessments are only available in the [en-US](./language-support.md?tabs=pronunciation-assessment) locale.

+| Method | Description |

+|--|-|

+| `EnableProsodyAssessment` | Enables prosody assessment for your pronunciation evaluation. This feature assesses aspects like stress, intonation, speaking speed, and rhythm, providing insights into the naturalness and expressiveness of your speech.<br/><br/>Enabling prosody assessment is optional. If this method is called, the `ProsodyScore` result value is returned. |

+| `EnableContentAssessmentWithTopic` | Enables content assessment. A content assessment is part of the [unscripted assessment](#unscripted-assessment-results) for the speaking language learning scenario. By providing a topic description via this method, you can enhance the assessment's understanding of the specific topic being spoken about. For example, in C# call `pronunciationAssessmentConfig.EnableContentAssessmentWithTopic("greeting");`, you can replace 'greeting' with your desired text to describe a topic. The topic value has no length limit and currently only supports `en-US` locale . |

+ 1. Under the `dotnet publish` step, add a step to install the [Entity Framework Core tool](/ef/core/cli/dotnet) with the command `dotnet tool install -g dotnet-ef --version 7.0.14`.

+ // in the case request is a preflight or invalid, directly return prebuild response by extension.

+ if (wpsContext.IsPreflight || wpsContext.HasError)

+ // in the case request is a preflight or invalid, directly return prebuild response by extension.

+ // return an http response with connect event response as body.

+1. Install Notation v1.0.1 on a Linux amd64 environment. You can also download the package for other environments by following the [Notation installation guide](https://notaryproject.dev/docs/user-guides/installation/).

+ curl -Lo notation.tar.gz https://github.com/notaryproject/notation/releases/download/v1.0.1/notation_1.0.1_linux_amd64.tar.gz

+Learn about the key concepts and components of Azure Load Testing. This information can help you to more effectively set up a load test to identify performance issues in your application.

+The ramp-up time is the amount of time to get to the full number of [virtual users](#virtual-users) for the load test. If the number of virtual users is 20, and the ramp-up time is 120 seconds, then it takes 120 seconds to get to all 20 virtual users. Each virtual user will start 6 (120/20) seconds after the previous user was started.

+The response time of an individual request, or [elapsed time in JMeter](https://jmeter.apache.org/usermanual/glossary.html), is the total time from just before sending the request to just after the last response is received. The response time doesn't include the time to render the response. Any client code, such as JavaScript, isn't processed during the load test.

+The latency of an individual request is the total time from just before sending the request to just after the first response is received. Latency includes all the processing needed to assemble the request and assembling the first part of the response.

+For example, given an application latency of 20 milliseconds (0.02 seconds), to simulate 100,000 RPS, you should configure the load test with 2,000 virtual users (100,000 * 0.02).

+Learn about the key concepts and components of Azure Load Testing. The following diagram gives an overview of how the different concepts relate to one another.

+Azure Load Testing lets you [use managed identities](./how-to-use-a-managed-identity.md) to access Azure Key Vault for storing [load test secret parameters or certificates](./how-to-parameterize-load-tests.md). You can use either a user-assigned or system-assigned managed identity.

+A test describes the load test configuration for your application. You add a test to an existing Azure load testing resource.

+A test contains a test plan, which describes the steps to invoke the application endpoint. You can define the test plan in either of two ways:

+- [Upload a JMeter test script](./how-to-create-and-run-load-test-with-jmeter-script.md).

+- [Specify the list of URL endpoints to test](./quickstart-create-and-run-load-test.md).

+Azure Load Testing supports all communication protocols that JMeter supports, not only HTTP-based endpoints. For example, you might want to read from or write to a database or message queue in the test script.

+In addition, you can upload CSV input data files and JMeter configuration files to the test.

+When you start a test, Azure Load Testing deploys the JMeter test script, related files, and configuration to the test engine instances. The test engine instances then initiate the JMeter test script to simulate the application load.

+### Test run

+A test run represents one execution of a load test. When you run a test, the test run contains a copy of the configuration settings from the associated test.

+After the test run completes, you can [view and analyze the load test results in the Azure Load Testing dashboard](./tutorial-identify-bottlenecks-azure-portal.md) in the Azure portal.

+Alternately, you can [download the test logs](./how-to-diagnose-failing-load-test.md#download-apache-jmeter-worker-logs-for-your-load-test) and [export the test results file](./how-to-export-test-results.md).

+> [!IMPORTANT]

+> When you update a test, the existing test runs don't automatically inherit the new settings from the test. The new settings are only used by new test runs when you run the *test*. If you rerun an existing *test run*, the original settings of the test run are used.

+### Test engine

+A test engine is computing infrastructure, managed by Microsoft that runs the Apache JMeter test script. The test engine instances run the JMeter script in parallel. You can [scale out your load test](./how-to-high-scale-load.md) by configuring the number of test engine instances. Learn how to configure the number of [virtual users](#virtual-users), or simulate a target number of [requests per second](#requests-per-second-rps).

+The test engines are hosted in the same location as your Azure Load Testing resource. You can configure the Azure region when you create the Azure load testing resource.

+While the test script runs, Azure Load Testing collects and aggregates the Apache JMeter worker logs from all test engine instances. You can [download the logs for analyzing errors during the load test](./how-to-diagnose-failing-load-test.md).

+Learn more about which [Azure resource types that Azure Load Testing supports](./resource-supported-azure-resource-types.md).

+## Related content

+You encounter this message if your account doesn't have the necessary permissions to manage tests.

+The following tables describe the specific permissions given to each role. These permissions can include *Actions*, which give permissions, and *Not Actions*, which restrict them.

+ The following snippet is the example output:

+* [Get-AzRoleAssignment](/powershell/module/az.resources/get-azroleassignment) lists Azure role assignments at the specified scope. Without any parameters, this cmdlet returns all the role assignments made under the subscription. Use the `ExpandPrincipalGroups` parameter to list access assignments for the specified user, and the groups that the user belongs to.

+## Related content

+- Learn more about [diagnosing failing load tests](./how-to-diagnose-failing-load-test.md).

+You can [download the JMeter errors logs](./how-to-diagnose-failing-load-test.md) to troubleshoot errors during the load test.

+- Learn more about [diagnosing failing load tests](./how-to-diagnose-failing-load-test.md).

+ Title: Diagnose failing load tests

+description: Learn how you can diagnose and troubleshoot failing tests in Azure Load Testing. Download and analyze the Apache JMeter worker logs in the Azure portal.

+# Diagnose failing load tests in Azure Load Testing

+In this article, you learn how to diagnose and troubleshoot failing load tests in Azure Load Testing. Azure Load Testing provides several options to identify the root cause of a failing load test. For example, you can use the load test dashboard, or download the test results or test log files for an in-depth analysis. Alternately, configure server-side metrics to identify issues with application endpoint.

+Azure Load Testing uses two indicators to determine the outcome of a load test:

+- **Test status**: indicates whether the load test was able to start successfully and run the test script until the end. For example, the test status is *Failed* if there's an error in the JMeter test script, or if the [autostop listener](./how-to-define-test-criteria.md#auto-stop-configuration) interrupted the load test because too many requests failed.

+- **Test result**: indicates the result of evaluating the [test fail criteria](./how-to-define-test-criteria.md). If at least one of the test fail criteria was met, the test result is set to *Failed*.

+Depending on the indicator, you can use a different approach to identify the root cause of a test failure.

+## Prerequisites

+- An Azure account with an active subscription. If you don't have an Azure subscription, [create a free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

+- An Azure load testing resource that has a completed test run. If you need to create an Azure load testing resource, see [Create and run a load test](./quickstart-create-and-run-load-test.md).

+## Determine the outcome of a load test

+Use the following steps to get the outcome of a load test:

+# [Azure portal](#tab/portal)

+1. In the [Azure portal](https://portal.azure.com), and go to your load testing resource.

+1. Select **Tests** in the left pane, to view the list of tests.

+1. Select a test from the list to view all test runs for that test.

+ The list of test runs shows the **Test result** and **Test status** fields.

+ :::image type="content" source="media/how-to-find-download-logs/load-testing-test-runs-list.png" alt-text="Screenshot that shows the list of test runs in the Azure portal, highlighting the test result and test status columns." lightbox="media/how-to-find-download-logs/load-testing-test-runs-list.png":::

+1. Alternately, select a test run to view the load test dashboard for the test run.

+ :::image type="content" source="media/how-to-find-download-logs/load-testing-dashboard-failed-test.png" alt-text="Screenshot that shows the load test dashboard, highlighting status information for a failed test." lightbox="media/how-to-find-download-logs/load-testing-dashboard-failed-test.png":::

+# [GitHub Actions](#tab/github)

+1. In [GitHub](https://github.com), browse to your repository.

+1. Select **Actions**, and then select your workflow run from the list.

+ On the **Summary** page, the status of the GitHub Actions workflow reflects the outcome of the load test action.

+ :::image type="content" source="media/how-to-find-download-logs/github-actions-summary-failed-test.png" alt-text="Screenshot that shows the summary page for an Azure Pipelines run, highlighting the failed load test stage." lightbox="media/how-to-find-download-logs/github-actions-summary-failed-test.png":::

+1. Alternately, select the workflow job to view the GitHub Actions workflow log.

+ :::image type="content" source="media/how-to-find-download-logs/github-actions-load-testing-log.png" alt-text="Screenshot that shows the GitHub Actions workflow logs, highlighting the error statistics information for a load test run." lightbox="media/how-to-find-download-logs/github-actions-load-testing-log.png":::

+# [Azure Pipelines](#tab/pipelines)

+1. Sign in to your Azure DevOps organization (`https://dev.azure.com/<your-organization>`), and select your project.

+

+ Replace the `<your-organization>` text placeholder with your project identifier.

+1. Select **Pipelines** in the left navigation, and then select your CI/CD workflow.

+ You can view the test run status in Azure Pipelines on the pipeline run **Summary** page. The status of the pipeline reflects the status of the load test task.

+ :::image type="content" source="media/how-to-find-download-logs/azure-pipelines-summary-failed-test.png" alt-text="Screenshot that shows the summary page for an Azure Pipelines run, highlighting the failed load test stage.":::

+1. Alternately, drill down into the Azure Pipelines log.

+ :::image type="content" source="./media/how-to-find-download-logs/azure-pipelines-load-test-log.png" alt-text="Screenshot that shows the Azure Pipelines run log, displaying the load testing metrics and Azure portal link." lightbox="./media/how-to-find-download-logs/azure-pipelines-load-test-log.png":::

+## Diagnose test failures

+You can use a different approach for diagnosing a load test failure based whether Azure Load Testing was able to run and complete the test script or not.

+### Load test failed to complete

+When the load test fails to complete, the *test status* of the test run is set to *Failed*.

+A load test can fail to complete because of multiple reasons. Examples of why a load test doesn't finish:

+- There are errors in the JMeter test script.

+- The test script uses JMeter features that Azure Load Testing doesn't support. Learn about the [supported JMeter features](./resource-jmeter-support.md).

+- The test script references a file or plugin that isn't available on the test engine instance.

+- The autostop functionality interrupted the load test because too many requests are failing and the error rate exceeds the threshold. Learn more about the [autostop functionality in Azure Load Testing](./how-to-define-test-criteria.md#auto-stop-configuration).

+Use the following steps to help diagnose a test not finishing:

+1. Verify the error details on the load test dashboard.

+1. [Download and analyze the test logs](#download-apache-jmeter-worker-logs-for-your-load-test) to identify issues in the JMeter test script.

+1. [Download the test results](./how-to-export-test-results.md) to identify issues with individual requests.

+### Load test completed

+A load test might run the test script until the end (test status equals *Done*), but might not pass all the [test fail criteria](./how-to-define-test-criteria.md). If at least one of the test criteria didn't pass, the *test result* of the test run is set to *Failed*.

+Use the following steps to help diagnose a test failing to meet the test criteria:

+1. Review the [test fail criteria](./how-to-define-test-criteria.md) in the load test dashboard.

+1. Review the sampler statistics in the load test dashboard to further identify which requests in the test script might cause an issue.

+1. Review the client-side metrics in the load test dashboard. Optionally, you can filter the charts for a specific request by using the filter controls.

+1. [Download the test results](./how-to-export-test-results.md) to get error information for individual requests.

+1. Verify the test [engine health metrics](./how-to-high-scale-load.md#monitor-engine-instance-metrics) to identify possible resource contention on the test engines.

+1. Optionally, [add app components and monitor server-side metrics](./how-to-monitor-server-side-metrics.md) to identify performance bottlenecks for the application endpoint.

+## Download Apache JMeter worker logs for your load test

+When you run a load test, the Azure Load Testing test engines execute your Apache JMeter test script. During the load test, Apache JMeter stores detailed logging in the worker node logs. You can download these JMeter worker logs for each test run in the Azure portal. Azure Load Testing generates a worker log for each [test engine instance](./concept-load-testing-concepts.md#test-engine).

+> [!NOTE]

+> Azure Load Testing only records log messages with `WARN` or `ERROR` level in the worker logs.

+For example, if there's a problem with your JMeter script, the load test status is **Failed**. In the worker logs you might find additional information about the cause of the problem.

+To download the worker logs for an Azure Load Testing test run, follow these steps:

+1. In the [Azure portal](https://portal.azure.com), go to your Azure Load Testing resource.

+1. Select **Tests** to view the list of tests, and then select your load test from the list.

+1. From the list of test runs, select a test run to view the load test dashboard.

+1. On the dashboard, select **Download**, and then select **Logs**.

+ The browser should now start downloading a zipped folder that contains the JMeter worker node log file for each [test engine instance](./concept-load-testing-concepts.md#test-engine).

+ :::image type="content" source="media/how-to-find-download-logs/logs.png" alt-text="Screenshot that shows how to download the test log files from the test run details page.":::

+1. You can use any zip tool to extract the folder and access the log files.

+ The *worker.log* file can help you diagnose the root cause of a failing load test. In the screenshot, you can see that the test failed because of a missing file.

+ :::image type="content" source="media/how-to-find-download-logs/jmeter-log.png" alt-text="Screenshot that shows the JMeter log file content.":::

+## Related content

+- Learn how to [export the load test result](./how-to-export-test-results.md).

+- Learn how to [monitor server-side application metrics](./how-to-monitor-server-side-metrics.md).

+- Learn how to [get detailed insights for Azure App Service based applications](./concept-load-test-app-service.md#monitor).

+- Learn how to [compare multiple load test runs](./how-to-compare-multiple-test-runs.md).

+You can also use the test results to diagnose errors during a load test. The `responseCode` and `responseMessage` fields give you more information about failed requests. For more information about investigating errors, see [Diagnose failing load tests](./how-to-diagnose-failing-load-test.md).

+- Learn more about [Diagnosing failing load tests](./how-to-diagnose-failing-load-test.md).

+> Apache JMeter only reports requests that made it to the server and back, either successful or not. If Apache JMeter is unable to connect to your application, the actual number of requests per second will be lower than the maximum value. Possible causes might be that the server is too busy to handle the request, or that a TLS/SSL certificate is missing. To diagnose connection problems, you can check the **Errors** chart in the load testing dashboard and [download the load test log files](./how-to-diagnose-failing-load-test.md).

+When the load test completes with the Failed status, you can [download the test logs](./how-to-diagnose-failing-load-test.md#download-apache-jmeter-worker-logs-for-your-load-test).

+| Test log files | 6 months | Learn how to [download the logs for diagnosing failing load tests](./how-to-diagnose-failing-load-test.md). |

+In **Replicate** > **Web apps**, you can see a list of ASP.NET apps discovered on your environment.

+> [!NOTE]

+> The source path and the attribute value of App configurations and App directories together must be under 3000 characters in length. This can roughly be translated to around 15 entries (inclusive of both configurations and directories) of character length of about 200 each.

+In **Replicate** > **Target settings**, you can configure the target where the applications will be migrated to.

+1. Choose the subscription, resource group, and container registry resource to which the app container images should be pushed.

+> Only AKS clusters with Windows nodes are listed.

+In **Replicate** > **Deployment settings**, you can configure the application on the AKS cluster.

+Read replicas are primarily designed for scenarios where offloading queries is beneficial, and a slight lag is manageable. They are optimized to provide near realtime updates from the primary for most workloads, making them an excellent solution for read-heavy scenarios. However, it's important to note that they are not intended for synchronous replication scenarios requiring up-to-the-minute data accuracy. While the data on the replica eventually becomes consistent with the primary, there may be a delay, which typically ranges from a few seconds to minutes, and in some heavy workload or high-latency scenarios, this could extend to hours. Typically, read replicas in the same region as the primary has less lag than geo-replicas, as the latter often deals with geographical distance-induced latency. For more insights into the performance implications of geo-replication, refer to [Geo-replication](#geo-replication) section. The data on the replica eventually becomes consistent with the data on the primary. Use this feature for workloads that can accommodate this delay.

+ Title: Manage read replicas - Azure portal, REST API - Azure Database for PostgreSQL - Flexible Server

+description: Learn how to manage read replicas Azure Database for PostgreSQL - Flexible Server from the Azure portal and REST API.

+> [!NOTE]

+> Azure Database for PostgreSQL - Flexible Server is currently supporting the following features in Preview:

+>

+> - Promote to primary server (to maintain backward compatibility, please use promote to independent server and remove from replication, which keeps the former behavior)

+> - Virtual endpoints

+>

+> For these features, remember to use the API version `2023-06-01-preview` in your requests. This version is necessary to access the latest, albeit preview, functionalities of these features.

+#### [Portal](#tab/portal)

+#### [REST API](#tab/restapi)

+To obtain information about the configuration of a server in Azure Database for PostgreSQL - Flexible Server, especially to view settings for recently introduced features like storage auto-grow or private link, you should use the latest API version `2023-06-01-preview`. The `GET` request for this would be formatted as follows:

+```http request

+https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2023-06-01-preview

+```

+Replace `{subscriptionId}`, `{resourceGroupName}`, and `{serverName}` with your Azure subscription ID, the resource group name, and the name of the primary server you want to review, respectively. This request will give you access to the configuration details of your primary server, ensuring it is properly set up for creating a read replica.

+Review and note the following settings:

+ - Compute Tier, Processor, Size (ex `Standard_D8ads_v5`).

+ - Storage

+ - Type

+ - Storage size (ex `128`)

+ - autoGrow

+ - Network

+ - High Availability

+ - Enabled / Disabled

+ - Availability zone settings

+ - Backup settings

+ - Retention period

+ - Redundancy Options

+**Sample response**

+```json

+{

+ "sku": {

+ "name": "Standard_D8ads_v5",

+ "tier": "GeneralPurpose"

+ },

+ "systemData": {

+ "createdAt": "2023-11-22T16:11:42.2461489Z"

+ },

+ "properties": {

+ "replica": {

+ "role": "Primary",

+ "capacity": 5

+ },

+ "storage": {

+ "type": "",

+ "iops": 500,

+ "tier": "P10",

+ "storageSizeGB": 128,

+ "autoGrow": "Disabled"

+ },

+ "network": {

+ "publicNetworkAccess": "Enabled"

+ },

+ "dataEncryption": {

+ "type": "SystemManaged"

+ },

+ "authConfig": {

+ "activeDirectoryAuth": "Disabled",

+ "passwordAuth": "Enabled"

+ },

+ "fullyQualifiedDomainName": "{serverName}.postgres.database.azure.com",

+ "version": "15",

+ "minorVersion": "4",

+ "administratorLogin": "myadmin",

+ "state": "Ready",

+ "availabilityZone": "1",

+ "backup": {

+ "backupRetentionDays": 7,

+ "geoRedundantBackup": "Disabled",

+ "earliestRestoreDate": "2023-11-23T12:55:33.3443218+00:00"

+ },

+ "highAvailability": {

+ "mode": "Disabled",

+ "state": "NotEnabled"

+ },

+ "maintenanceWindow": {

+ "customWindow": "Disabled",

+ "dayOfWeek": 0,

+ "startHour": 0,

+ "startMinute": 0

+ },

+ "replicationRole": "Primary",

+ "replicaCapacity": 5

+ },

+ "location": "East US",

+ "tags": {},

+ "id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}",

+ "name": "{serverName}",

+ "type": "Microsoft.DBforPostgreSQL/flexibleServers"

+}

+```

+#### [Portal](#tab/portal)

+5. Select **Review + create** to confirm the creation of the replica or **Next: Networking** if you want to add, delete or modify any firewall rules.

+ :::image type="content" source="./media/how-to-read-replicas-portal/networking.png" alt-text="Screenshot of modify firewall rules action." lightbox="./media/how-to-read-replicas-portal/networking.png":::

+6. Leave the remaining defaults and then select the **Review + create** button at the bottom of the page or proceed to the next forms to add tags or change data encryption method.

+7. Review the information in the final confirmation window. When you're ready, select **Create**. A new deployment will be created and executed.

+ :::image type="content" source="./media/how-to-read-replicas-portal/replica-review.png" alt-text="Screenshot of reviewing the information in the final confirmation window.":::

+8. During the deployment, you see the primary in `Updating` state.

+

+ :::image type="content" source="./media/how-to-read-replicas-portal/primary-updating.png" alt-text="Screenshot of primary entering into updating status." lightbox="./media/how-to-read-replicas-portal/primary-updating.png":::

+ After the read replica is created, it can be viewed from the **Replication** window.

+ :::image type="content" source="./media/how-to-read-replicas-portal/list-replica.png" alt-text="Screenshot of viewing the new replica in the replication window." lightbox="./media/how-to-read-replicas-portal/list-replica.png":::

+#### [REST API](#tab/restapi)

+Initiate an `HTTP PUT` request by using the [create API](/rest/api/postgresql/flexibleserver/servers/create):

+```http

+PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{replicaserverName}?api-version=2022-12-01

+```

+Here, you need to replace `{subscriptionId}`, `{resourceGroupName}`, and `{replicaserverName}` with your specific Azure subscription ID, the name of your resource group, and the desired name for your read replica, respectively.

+```json

+{

+ "location": "eastus",

+ "properties": {

+ "createMode": "Replica",

+ "SourceServerResourceId": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{sourceserverName}"

+ }

+}

+```

+> To avoid issues during promotion of replicas constantly change the following server parameters on the replicas first, before applying them on the primary: `max_connections`, `max_prepared_transactions`, `max_locks_per_transaction`, `max_wal_senders`, `max_worker_processes`.

+> [!NOTE]

+> All operations involving virtual endpoints - like adding, editing, or removing - are executed in the context of the primary server.

+#### [Portal](#tab/portal)

+1. In the Azure portal, select the primary server.

+2. On the server sidebar, under **Settings**, select **Replication**.

+3. Select **Create endpoint**.

+4. In the dialog, type a meaningful name for your endpoint. Notice the DNS endpoint that is being generated.

+5. Select **Create**.

+#### [REST API](#tab/restapi)

+To create a virtual endpoint in a preview environment using Azure's REST API, you would use an `HTTP PUT` request. The request would look like this:

+```http

+PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{sourceserverName}/virtualendpoints/{virtualendpointName}?api-version=2023-06-01-preview

+```

+The accompanying JSON body for this request is as follows:

+```json

+{

+ "Properties": {

+ "EndpointType": "ReadWrite",

+ "Members": ["{replicaserverName}"]

+ }

+}

+```

+Here, `{replicaserverName}` should be replaced with the name of the replica server you're including as a reader endpoint target in this virtual endpoint.

+## List virtual endpoints (preview)

+To list virtual endpoints in the preview version of Azure Database for PostgreSQL - Flexible Server, use the following steps:

+#### [Portal](#tab/portal)

+1. In the Azure portal, select the **primary** server.

+2. On the server sidebar, under **Settings**, select **Replication**.

+3. At the top of the page, you will see both the reader and writer endpoints displayed, along with the names of the servers they are pointing to.

+ :::image type="content" source="./media/how-to-read-replicas-portal/virtual-endpoints-show.png" alt-text="Screenshot of virtual endpoints list." lightbox="./media/how-to-read-replicas-portal/virtual-endpoints-show.png":::

+#### [REST API](#tab/restapi)

+```http request

+GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{sourceserverName}/virtualendpoints?api-version=2023-06-01-preview

+```

+Here, `{sourceserverName}` should be the name of the primary server from which you're managing the virtual endpoints.

+Modify any applications that are using your Azure Database for PostgreSQL to use the new virtual endpoints (ex: `corp-pg-001.writer.postgres.database.azure.com` and `corp-pg-001.reader.postgres.database.azure.com`).

+#### [Portal](#tab/portal)

+#### [REST API](#tab/restapi)

+When promoting a replica to a primary server, use an `HTTP PATCH` request with a specific `JSON` body to set the promotion options. This process is crucial when you need to elevate a replica server to act as the primary server.

+The `HTTP` request is structured as follows:

+```http

+PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{replicaserverName}?api-version=2023-06-01-preview

+```

+```json

+{

+ "Properties": {

+ "Replica": {

+ "PromoteMode": "switchover",

+ "PromoteOption": "planned"

+ }

+ }

+}

+```

+In this `JSON`, the promotion is set to occur in `switchover` mode with a `planned` promotion option. While there are two options for promotion - `planned` or `forced` - chose `planned` for this exercise.

+

+Repeat the same operations to promote the original server to the primary.

+#### [Portal](#tab/portal)

+#### [REST API](#tab/restapi)

+This time, change the `{replicaserverName}` in the API request to refer to your old primary server, which is currently acting as a replica, and execute the request again.

+```http

+PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{replicaserverName}?api-version=2023-06-01-preview

+```

+```json

+{

+ "Properties": {

+ "Replica": {

+ "PromoteMode": "switchover",

+ "PromoteOption": "planned"

+ }

+ }

+}

+```

+In this `JSON`, the promotion is set to occur in `switchover` mode with a `planned` promotion option. While there are two options for promotion - `planned` or `forced` - chose `planned` for this exercise.

+#### [Portal](#tab/portal)

+9. During the deployment, you see the primary in `Updating` state.

+

+ :::image type="content" source="./media/how-to-read-replicas-portal/primary-updating.png" alt-text="Screenshot of primary entering into updating status." lightbox="./media/how-to-read-replicas-portal/primary-updating.png":::

+#### [REST API](#tab/restapi)

+You can create a secondary read replica by using the [create API](/rest/api/postgresql/flexibleserver/servers/create):

+```http

+PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{replicaserverName}?api-version=2022-12-01

+```

+Choose a distinct name for `{replicaserverName}` to differentiate it from the primary server and any other replicas.

+```json

+{

+ "location": "westus3",

+ "properties": {

+ "createMode": "Replica",

+ "SourceServerResourceId": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{sourceserverName}"

+ }

+}

+```

+The location is set to `westus3`, but you can adjust this based on your geographical and operational needs.

+#### [Portal](#tab/portal)

+#### [REST API](#tab/restapi)

+You can now modify your reader endpoint to point to the newly created secondary replica by using a `PATCH` request. Remember to replace `{replicaserverName}` with the name of the newly created read replica.

+```http

+PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{sourceserverName}/virtualendpoints/{virtualendpointName}?api-version=2023-06-01-preview

+```

+```json

+{

+ "Properties": {

+ "EndpointType": "ReadWrite",

+ "Members": ["{replicaserverName}"]

+ }

+}

+```

+#### [Portal](#tab/portal)

+#### [REST API](#tab/restapi)

+You can promote a replica to a standalone server using a `PATCH` request. To do this, send a `PATCH` request to the specified Azure Management REST API URL with the first `JSON` body, where `PromoteMode` is set to `standalone` and `PromoteOption` to `planned`. The second `JSON` body format, setting `ReplicationRole` to `None`, is deprecated but still mentioned here for backward compatibility.

+```http

+PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{replicaserverName}?api-version=2023-06-01-preview

+```

+```json

+{

+ "Properties": {

+ "Replica": {

+ "PromoteMode": "standalone",

+ "PromoteOption": "planned"

+ }

+ }

+}

+```

+```json

+{

+ "Properties": {

+ "ReplicationRole": "None"

+ }

+}

+```

+ > [!NOTE]

+ > Once a replica is promoted to an independent server, it cannot be added back to the replication set.

+

+## Delete virtual endpoint (preview)

+#### [Portal](#tab/portal)

+1. In the Azure portal, select the **primary** server.

+2. On the server sidebar, under **Settings**, select **Replication**.

+3. At the top of the page, locate the `Virtual endpoints (Preview)` section. Navigate to the three dots (menu options) next to the endpoint name, expand it, and choose `Delete`.

+4. A delete confirmation dialog will appear. It will warn you: "This action will delete the virtual endpoint `virtualendpointName`. Any clients connected using these domains may lose access." Acknowledge the implications and confirm by clicking on **Delete**.

+#### [REST API](#tab/restapi)

+To delete a virtual endpoint in a preview environment using Azure's REST API, you would issue an `HTTP DELETE` request. The request URL would be structured as follows:

+```http

+DELETE https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{serverName}/virtualendpoints/{virtualendpointName}?api-version=2023-06-01-preview

+```

+#### [Portal](#tab/portal)

+#### [REST API](#tab/restapi)

+To delete a primary or replica server, use the [delete API](/rest/api/postgresql/flexibleserver/servers/delete). If server has read replicas then read replicas should be deleted first before deleting the primary server.

+```http

+DELETE https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{replicaserverName}?api-version=2022-12-01

+```

+#### [Portal](#tab/portal)

+#### [REST API](#tab/restapi)

+To delete a primary or replica server, use the [delete API](/rest/api/postgresql/flexibleserver/servers/delete). If server has read replicas then read replicas should be deleted first before deleting the primary server.

+```http

+DELETE https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{sourceserverName}?api-version=2022-12-01

+```

+- [Read replicas in Azure Database for PostgreSQL](concepts-read-replicas.md)

+- Log in to Azure account using [az login](/cli/azure/reference-index#az-login) command. Note the **id** property, which refers to **Subscription ID** for your Azure account.

+- Create a PostgreSQL Flexible Server if you haven't already created one using the ```az postgres flexible-server create``` command.

+To stop a server, run ```az postgres flexible-server stop``` command. If you're using [local context](/cli/azure/config/param-persist), you don't need to provide any arguments.

+To start a server, run ```az postgres flexible-server start``` command. If you're using [local context](/cli/azure/config/param-persist), you don't need to provide any arguments.

+ location='<location>',

+ version="16",

+- **server_name**: A unique name that identifies your Azure Database for PostgreSQL - Flexible Server. The domain name `postgres.database.azure.com` is appended to the server name you provide. The server name must be at least 3 characters and at most 63 characters, and can only contain lowercase letters, numbers, and hyphens.

+- **location**: The Azure region where you want to create your Azure Database for PostgreSQL - Flexible Server. It defines the geographical location where your server and its data reside. Choose a region close to your users for reduced latency. The location should be specified in the format of Azure region short names, like `westus2`, `eastus`, or `northeurope`.

+You can also customize other parameters like storage size, engine version, etc.

+Information retrieval is foundational to any app that surfaces text and vectors. Common scenarios include catalog or document search, data exploration, and increasingly chat-style copilot apps over proprietary grounding data. When you create a search service, you work with the following capabilities:

+The **SequenceNumber** for a scheduled message is only valid while the message is in this state. As the message transitions to the active state, the message is appended to the queue as if it had been enqueued at the current instant, which includes assigning a new **SequenceNumber**.

+The Red Hat images provided in Azure Marketplace are connected by default to one of two different types of life-cycle repositories:

+- Non-EUS: Will have the latest available software published by Red Hat for their particular Red Hat Enterprise Linux (RHEL) repositories.

+- Extended Update Support (EUS): Updates won't go beyond a specific RHEL minor release.

+> [!NOTE]

+> For more information on RHEL EUS, see [Red Hat Enterprise Linux Life Cycle](https://access.redhat.com/support/policy/updates/errata) and [Red Hat Enterprise Linux Extended Update Support Overview](https://access.redhat.com/articles/rhel-eus).

+The packages contained in the Red Hat Update Infrastructure repositories are published and maintained exclusively by Red Hat, extra packages to support custom Azure services, are published in independent repositories maintained by Microsoft.

+RHEL VM images connected to non-EUS repositories, it will upgrade to the latest RHEL minor version when you run `sudo yum update`. For example, if you provision a VM from a RHEL 8.4 PAYG image and run `sudo yum update`, you end up with a RHEL 8.9 VM, the latest minor version in the RHEL8 family.

+RedHat:RHEL:7.7:7.7.2022051301

+RedHat:RHEL:8_4:latest

+RedHat:RHEL:9_0:9.0.2023061412

+> [!NOTE]

+> Not all minor versions are valid EUS stops, for example, for RHEL8 only 8.1, 8.2, 8.4, 8.6 and 8.8 are valid EUS releases, while 8.3, 8.5 and 8.7 are not.

+Run the following commands as root: