Blog Post

Azure SQL Blog
2 MIN READ

Azure SQL Database Hyperscale - Named Replicas feature is Generally Available (GA)

Attinder_Pal_Singh's avatar
Attinder_Pal_Singh
Icon for Microsoft rankMicrosoft
Jun 22, 2022

We are happy to announce General Availability of Named replicas in the Hyperscale tier of Azure SQL Database. We released public preview of this feature in June 2021, since then this feature has been improved and adopted by many customers across industries.

 

Named replicas is an addition to Azure SQL Database Hyperscale to scale-out a variety of read workloads, be it highly concurrent OLTP workloads or HTAP solutions for real-time data analytics.

 

Named Replicas uses cases:

  • Flexibility: Scale-out read workloads to up to 30 read replicas. Each replica can be scaled to different compute size (Service Level Objectives) than primary compute, to cater to dynamic workloads. For example, new replicas can be added, or existing replicas can be scaled-up to cater peak times like end of month processing/sale period, etc and scale down during lean business times.
  • Isolation: Multiple application users can work in isolation on their respective named replica as logins/AD group can be granted isolated access and dedicated connection endpoint to respective replica.
  • Cost savings for read scale-out: Since named replicas share same storage as primary replica, storage cost is saved, and license charge does not apply to named replicas. There are additional cost savings opportunities when named replicas can be scaled down compared to the primary.
  • Serve modern application architectures for Analytical workloads including Data Science and Reporting.

Reference architecture diagram shared below explains utilization of Azure SQL Database Hyperscale for a variety of workloads. Reporting Application 2 connects to a named replica having smaller compute size than primary. Another two named replicas are utilized by Application 3 for Analytical workloads both scaled to different compute sizes to cater to dynamic workloads.

 

Hyperscale Reference Architecture

 

Named Replicas documentation: Hyperscale secondary replicas - Azure SQL Database | Microsoft Docs

Named Replicas FAQs: Azure SQL Database Hyperscale named replicas FAQ - Azure SQL | Microsoft Docs

Sample to enable OLTP read scale-out using Named Replicas: Azure-Samples (github.com)

Customer Story: Build fast, scalable data system on Azure SQL Database Hyperscale | Clearent

 

 

 

 

Updated Jun 22, 2022
Version 3.0
azure sql
azure sql database
  • GermanD80's avatar
    GermanD80
    Copper Contributor
    Mar 20, 2024

    Why queries to the named replica too slow when the primary database is under load? simple queries take between 1 and 2 minutes

  • Attinder_Pal_Singh's avatar
    Attinder_Pal_Singh
    Icon for Microsoft rankMicrosoft
    Oct 24, 2024

    GermanD80: There could be multiple factors for the same and it could be environment specific as well. I would suggest raising an incident with Microsoft support team to perform through investigation. I am sharing few of the scenarios below:

    - Data Latency

    Named replicas rely on the transaction log service to keep data in sync with the primary replica. If the primary database is under heavy load, the rate at which transaction logs are generated and forwarded to the named replicas can increase, leading to higher data latency. This means that the named replica might not have the most recent data, causing delays in query execution. 

    You can use Azure Monitor/DMVs to track data latency between the primary and named replicas. This can help identify if high latency is contributing to the slow query performance.

    - Resource Contention

    Heavy load on the primary database can lead to resource contention, affecting the performance of the transaction log service and other background processes that are responsible for syncing data with named replicas. 

    - Compute and Storage Configuration

    The performance of named replicas can also be influenced by their compute size. If the named replicas are not provisioned with sufficient resources (e.g., vCores/service level objective (SLO)), they may struggle to handle the query load, especially when the primary database is under stress. Please ensure that the named replicas are provisioned with adequate compute resources to handle the query load. Adjust the service level objective (SLO) if necessary to provide more resources.