Applications that require guaranteed data consistency across sessions, or require committed data to be readable immediately should use the primary replica. Conditions such as high resource utilization on the replica can increase latency substantially. However, there is no fixed upper bound on data propagation latency.
Typical data propagation latency between the primary replica and read-only replicas varies in the range from tens of milliseconds to single-digit seconds. Likewise, if an application changes data using a read-write session on the primary and immediately reads it using a read-only session on a read-only replica, it is possible that the latest changes will not be immediately visible. If a read-only replica becomes unavailable and a session reconnects, it may connect to a replica that is at a different point in time than the original replica. Because data propagation latency is variable, different replicas can return data at slightly different points in time relative to the primary and each other. Within a session connected to a read-only replica, reads are always transactionally consistent. However, for all replica types, reads from a read-only replica are always asynchronous with respect to the primary. Data consistencyĭata changes made on the primary replica are persisted on read-only replicas synchronously or asynchronously depending on replica type. Query Store and SQL Profiler features are not supported on read-only replicas. The read scale-out feature is enabled by default on new Premium, Business Critical, and Hyperscale databases. The following diagram illustrates the feature for Premium and Business Critical databases and managed instances. However, geo-replicas can provide similar functionality in these service tiers. The read scale-out feature is not available in these service tiers. The High Availability architecture of Basic, Standard, and General Purpose service tiers does not include any replicas. Multiple secondary HA replicas can be used for load-balancing read-only workloads that require more resources than available on one secondary HA replica. Hyperscale secondary named replicas provide independent scaling, access isolation, workload isolation, support for a variety of read scale-out scenarios, and other benefits.
The read scale-out feature is also available in the Hyperscale service tier when at least one secondary replica is added. In the Premium and Business Critical service tiers, applications could gain performance benefits using this additional capacity at no extra cost. The feature is intended for the applications that include logically separated read-only workloads, such as analytics.
This way, some read-only workloads can be isolated from the read-write workloads, and will not affect their performance. The read scale-out feature allows you to offload read-only workloads using the compute capacity of one of the read-only replicas, instead of running them on the read-write replica. The secondary replicas are provisioned with the same compute size as the primary replica. As part of High Availability architecture, each single database, elastic pool database, and managed instance in the Premium and Business Critical service tier is automatically provisioned with a primary read-write replica and several secondary read-only replicas.
0 kommentar(er)
