Alleen-lezen replica's gebruiken om alleen-lezen queryworkloads te offloaden

Van toepassing op: Azure SQL DatabaseAzure SQL Managed Instance

Als onderdeel van architectuur met hoge beschikbaarheid wordt elke individuele database of elastische pooldatabase in de Premium- en Bedrijfskritiek-servicelaag automatisch ingericht met een primaire replica voor lezen/schrijven en een of meer secundaire alleen-lezen replica's. De secundaire replica's worden ingericht met dezelfde rekenkracht als de primaire replica. Met de uitschaalfunctie voor lezen kunt u alleen-lezen workloads offloaden met behulp van de rekencapaciteit van een van de alleen-lezen replica's, in plaats van ze uit te voeren op de lees-/schrijfreplica. Op deze manier kunnen sommige alleen-lezen workloads worden geïsoleerd van de lees-schrijfworkloads en zijn ze niet van invloed op hun prestaties. De functie is bedoeld voor de toepassingen die logisch gescheiden alleen-lezenworkloads bevatten, zoals analyses. In de Premium- en Bedrijfskritiek-servicelagen kunnen toepassingen prestatievoordelen krijgen met behulp van deze extra capaciteit zonder extra kosten.

De uitschaalfunctie voor lezen is ook beschikbaar in de Hyperscale-servicelaag wanneer ten minste één secundaire replica wordt toegevoegd. Secundaire replica's met Hyperscale bieden onafhankelijk schalen, toegangsisolatie, workloadisolatie, ondersteuning voor verschillende scenario's voor uitschalen van leesbewerkingen en andere voordelen. Er kunnen meerdere secundaire HA-replica's worden gebruikt voor taakverdeling voor alleen-lezen workloads waarvoor meer resources nodig zijn dan beschikbaar is op één secundaire HA-replica.

De architectuur met hoge beschikbaarheid van de servicelagen Basic, Standard en Algemeen bevat geen replica's. De uitschaalfunctie voor lezen is niet beschikbaar in deze servicelagen. Bij het gebruik van Azure SQL Database kunnen geo-replica's echter vergelijkbare functionaliteit bieden in deze servicelagen. Wanneer u Azure SQL Managed Instance en failovergroepen gebruikt, kan de listener met het kenmerk Alleen-lezen van de failovergroep respectievelijk vergelijkbare functionaliteit bieden.

In het volgende diagram ziet u de functie voor Premium- en Bedrijfskritiek-databases en beheerde exemplaren.

De uitschaalfunctie voor lezen is standaard ingeschakeld voor nieuwe Premium-, Bedrijfskritiek- en Hyperscale-databases.

Notitie

Uitschalen van leesbewerkingen is altijd ingeschakeld in de servicelaag Bedrijfskritiek van SQL Managed Instance en voor Hyperscale-databases met ten minste één secundaire replica.

Als uw SQL-verbindingsreeks is geconfigureerd, ApplicationIntent=ReadOnlywordt de toepassing omgeleid naar een alleen-lezen replica van die database of het beheerde exemplaar. Zie Toepassingsintentie opgeven voor informatie over het gebruik van de ApplicationIntent eigenschap.

Alleen voor Azure SQL Database moet u, als u ervoor wilt zorgen dat de toepassing verbinding maakt met de primaire replica, ongeacht de ApplicationIntent instelling in de SQL-verbindingsreeks, de uitschalen van leesbewerkingen expliciet uitschakelen bij het maken van de database of bij het wijzigen van de configuratie. Als u bijvoorbeeld uw database bijwerkt van de laag Standard of Algemeen gebruik naar Premium of Bedrijfskritiek en ervoor wilt zorgen dat al uw verbindingen naar de primaire replica blijven gaan, schakelt u uitschalen van leesbewerkingen uit. Zie Uitschalen van leesbewerkingen in- en uitschakelen voor meer informatie over het uitschakelen ervan.

Notitie

Query Store- en SQL Profiler-functies worden niet ondersteund op alleen-lezen replica's.

Gegevensconsistentie

Gegevenswijzigingen die zijn aangebracht op de primaire replica, worden synchroon of asynchroon op alleen-lezen replica's bewaard, afhankelijk van het replicatype. Voor alle replicatypen zijn leesbewerkingen van een alleen-lezen replica echter altijd asynchroon ten opzichte van de primaire replica. Binnen een sessie die is verbonden met een alleen-lezen replica, zijn leesbewerkingen altijd transactioneel consistent. Omdat de latentie van gegevensdoorgifte variabel is, kunnen verschillende replica's gegevens op iets verschillende tijdstippen retourneren ten opzichte van de primaire en elkaar. Als een alleen-lezen replica niet meer beschikbaar is en een sessie opnieuw verbinding maakt, kan deze verbinding maken met een replica die zich op een ander tijdstip bevindt dan de oorspronkelijke replica. Als een toepassing gegevens wijzigt met behulp van een lees-/schrijfsessie op de primaire en deze onmiddellijk leest met behulp van een alleen-lezensessie op een replica met het kenmerk Alleen-lezen, is het mogelijk dat de meest recente wijzigingen niet onmiddellijk zichtbaar zijn.

Typische latentie van gegevensdoorgifte tussen de primaire replica en alleen-lezen replica's varieert in het bereik van tientallen milliseconden tot seconden met één cijfer. Er is echter geen vaste bovengrens voor gegevensdoorgiftelatentie. Voorwaarden zoals een hoog resourcegebruik op de replica kunnen de latentie aanzienlijk verhogen. Toepassingen waarvoor gegarandeerde gegevensconsistentie tussen sessies is vereist of waarvoor vastgelegde gegevens onmiddellijk leesbaar moeten zijn, moeten gebruikmaken van de primaire replica.

Notitie

Latentie van gegevensdoorgifte omvat de tijd die nodig is voor het verzenden en behouden van logboekrecords (indien van toepassing) naar een secundaire replica. Het bevat ook de tijd die nodig is om deze logboekrecords opnieuw uit te voeren (toe te passen) op gegevenspagina's. Om gegevensconsistentie te garanderen, zijn wijzigingen pas zichtbaar als de logboekrecord voor transactiedoorvoering is toegepast. Wanneer de workload grotere transacties gebruikt, wordt de effectieve latentie voor gegevensdoorgifte verhoogd.

Als u de latentie van gegevensdoorgifte wilt bewaken, raadpleegt u Controleren en problemen met alleen-lezenreplica oplossen.

Verbinding maken naar een alleen-lezen replica

Wanneer u uitschalen van leesbewerkingen voor een database inschakelt, bepaalt de ApplicationIntent optie in de verbindingsreeks van de client of de verbinding wordt doorgestuurd naar de schrijfreplica of naar een alleen-lezen replica. Als de ApplicationIntent waarde (de standaardwaarde) is ReadWrite , wordt de verbinding omgeleid naar de lees-/schrijfreplica. Dit is identiek aan het gedrag wanneer ApplicationIntent deze niet is opgenomen in de verbindingsreeks. Als de ApplicationIntent waarde is ReadOnly, wordt de verbinding doorgestuurd naar een alleen-lezen replica.

Het volgende verbindingsreeks de client bijvoorbeeld verbindt met een alleen-lezen replica (waarbij de items in de punthaken worden vervangen door de juiste waarden voor uw omgeving en de punthaken verwijderen):

Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

Als u verbinding wilt maken met een alleen-lezen replica met behulp van SQL Server Management Studio (SSMS), selecteert u Opties

Selecteer Aanvullende parameters voor Verbinding maken ion en voer deze in ApplicationIntent=ReadOnly en selecteer Verbinding maken

Een van de volgende verbindingsreeks verbindt de client met een lees-/schrijfreplica (waarbij de items in de punthaken worden vervangen door de juiste waarden voor uw omgeving en de punthaken verwijderen):

Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadWrite;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

Server=tcp:<server>.database.windows.net;Database=<mydatabase>;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

Controleer of een verbinding is met een alleen-lezen replica

U kunt controleren of u bent verbonden met een alleen-lezen replica door de volgende query uit te voeren in de context van uw database. Het retourneert READ_ONLY wanneer u bent verbonden met een alleen-lezen replica.

SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability');

Notitie

In Premium- en Bedrijfskritiek-servicelagen is op elk gewenst moment slechts één van de alleen-lezen replica's toegankelijk. Hyperscale ondersteunt meerdere alleen-lezen replica's.

Alleen-lezenreplica's bewaken en problemen oplossen

Wanneer u verbinding maakt met een alleen-lezen replica, weerspiegelen dynamische beheerweergaven (DMV's) de status van de replica en kunnen ze worden opgevraagd voor bewakings- en probleemoplossingsdoeleinden. De database-engine biedt meerdere weergaven om een breed scala aan bewakingsgegevens beschikbaar te maken.

De volgende weergaven worden vaak gebruikt voor replicabewaking en probleemoplossing:

Naam	Doel
sys.dm_db_resource_stats	Biedt metrische gegevens over resourcegebruik voor het afgelopen uur, waaronder CPU, gegevens-I/O en schrijfgebruik van logboeken ten opzichte van servicedoelstellinglimieten.
sys.dm_os_wait_stats	Biedt statistische wachtstatistieken voor het exemplaar van de database-engine.
sys.dm_database_replica_states	Biedt statistieken over de status en synchronisatie van replica's. De grootte van de wachtrij en het opnieuw uitvoeren van de wachtrij worden gebruikt als indicatoren voor de latentie van gegevensdoorgifte op de alleen-lezen replica.
sys.dm_os_performance_counters	Biedt prestatiemeteritems voor de database-engine.
sys.dm_exec_query_stats	Biedt uitvoeringsstatistieken per query, zoals het aantal uitvoeringen, de GEBRUIKTE CPU-tijd, enzovoort.
sys.dm_exec_query_plan()	Biedt queryplannen in de cache.
sys.dm_exec_sql_text()	Biedt querytekst voor een queryplan in de cache.
sys.dm_exec_query_profiles	Biedt realtime queryvoortgang terwijl query's worden uitgevoerd.
sys.dm_exec_query_plan_stats()	Biedt het laatst bekende werkelijke uitvoeringsplan, inclusief runtimestatistieken voor een query.
sys.dm_io_virtual_file_stats()	Biedt opslagstatistieken voor IOPS, doorvoer en latentie voor alle databasebestanden.

Notitie

De sys.resource_stats en sys.elastic_pool_resource_stats DMV's in de logische master database retourneren resourcegebruiksgegevens van de primaire replica.

Alleen-lezen replica's bewaken met uitgebreide gebeurtenissen

Er kan geen uitgebreide gebeurtenissessie worden gemaakt wanneer deze is verbonden met een alleen-lezen replica. In Azure SQL Database zijn echter de definities van uitgebreide gebeurtenissessies met databasebereik gemaakt en gewijzigd op de primaire replicareplicatie naar alleen-lezen replica's, inclusief geo-replica's, en vastleggen van gebeurtenissen op alleen-lezen replica's.

Een uitgebreide gebeurtenissessie op een alleen-lezen replica die is gebaseerd op een sessiedefinitie van de primaire replica, kan onafhankelijk van de sessie op de primaire replica worden gestart en gestopt.

Als u een gebeurtenissessie wilt verwijderen op een alleen-lezen replica, voert u de volgende stappen uit:

1. Verbinding maken SSMS-Objectverkenner of een queryvenster naar de alleen-lezen replica.
2. Stop de sessie op de alleen-lezen replica door Sessie stoppen te selecteren in het contextmenu van de sessie in Objectverkenner of door deze uit te ALTER EVENT SESSION [session-name-here] ON DATABASE STATE = STOP; voeren in een queryvenster.
3. Verbinding maken Objectverkenner of een queryvenster naar de primaire replica.
4. Verwijder de sessie op de primaire replica door Verwijderen te selecteren in het contextmenu van de sessie of door de sessie uit te voerenDROP EVENT SESSION [session-name-here] ON DATABASE;

Niveau van transactieisolatie op alleen-lezen replica's

Transacties op alleen-lezenreplica's gebruiken altijd het isolatieniveau van momentopnametransacties, ongeacht het transactie-isolatieniveau van de sessie en ongeacht eventuele queryhints. Isolatie van momentopnamen maakt gebruik van rijversiebeheer om blokkerende scenario's te voorkomen waarbij lezers schrijvers blokkeren.

Als een isolatietransactie voor momentopnamen in zeldzame gevallen toegang heeft tot objectmetagegevens die zijn gewijzigd in een andere gelijktijdige transactie, kan fout 3961 worden weergegeven: 'De transactie voor isolatie van momentopnamen is mislukt in database %.*ls' omdat het object dat door de instructie is geopend, is gewijzigd door een DDL-instructie in een andere gelijktijdige transactie sinds het begin van deze transactie. Dit is niet toegestaan omdat versiebeheer niet is ingeschakeld voor de metagegevens. Een gelijktijdige update van metagegevens kan leiden tot inconsistentie als deze wordt gecombineerd met isolatie van momentopnamen.'

Langlopende query's op alleen-lezen replica's

Query's die worden uitgevoerd op alleen-lezen replica's moeten toegang hebben tot metagegevens voor de objecten waarnaar wordt verwezen in de query (tabellen, indexen, statistieken, enzovoort) In zeldzame gevallen, als objectmetagegevens worden gewijzigd op de primaire replica terwijl een query een vergrendeling op hetzelfde object op de alleen-lezen replica bevat, kan de query het proces blokkeren dat wijzigingen van de primaire replica toepast op de alleen-lezen replica. Als een dergelijke query lange tijd zou worden uitgevoerd, zou dit ertoe leiden dat de alleen-lezenreplica aanzienlijk niet synchroon is met de primaire replica. Voor replica's die mogelijke failoverdoelen zijn (secundaire replica's in Premium- en Bedrijfskritiek servicelagen, Hyperscale HA-replica's en alle geo-replica's), zou dit ook het herstel van de database vertragen als er een failover zou optreden, wat langer dan verwachte downtime zou veroorzaken.

Als een langlopende query op een alleen-lezen replica direct of indirect dit soort blokkeringen veroorzaakt, wordt deze mogelijk automatisch beëindigd om overmatige gegevenslatentie en mogelijke gevolgen voor databasebeschikbaarheid te voorkomen. De sessie ontvangt fout 1219: 'Uw sessie is verbroken vanwege een DDL-bewerking met hoge prioriteit', of fout 3947: 'De transactie is afgebroken omdat de secundaire berekening de redo niet kon inhalen. Voer de transactie opnieuw uit.

Notitie

Als u fout 3961, 1219 of 3947 ontvangt bij het uitvoeren van query's op een alleen-lezen replica, voert u de query opnieuw uit. U kunt ook bewerkingen voorkomen die objectmetagegevens wijzigen (schemawijzigingen, indexonderhoud, updates van statistieken, enzovoort) op de primaire replica terwijl langlopende query's worden uitgevoerd op secundaire replica's.

Tip

In Premium- en Bedrijfskritiek-servicelagen, wanneer deze zijn verbonden met een alleen-lezen replica, kunnen de redo_queue_size en redo_rate kolommen in de sys.dm_database_replica_states DMV worden gebruikt om het proces van gegevenssynchronisatie te bewaken, wat fungeert als indicatoren van de latentie van gegevensdoorgifte op de alleen-lezen replica.

Uitschalen van leesbewerkingen voor SQL Database in- en uitschakelen

Voor SQL Managed Instance wordt het uitschalen van leesbewerkingen automatisch ingeschakeld op de servicelaag Bedrijfskritiek en is deze niet beschikbaar in de servicelaag Algemeen gebruik. Het uitschakelen en opnieuw inschakelen van uitschalen van leesbewerkingen is niet mogelijk.

Voor SQL Database is uitschalen van leesbewerkingen standaard ingeschakeld voor Premium-, Bedrijfskritiek- en Hyperscale-servicelagen. Uitschalen van leesbewerkingen kan niet worden ingeschakeld in servicelagen Basic, Standard of Algemeen gebruik. Uitschalen van lezen wordt automatisch uitgeschakeld op Hyperscale-databases die zijn geconfigureerd met nul secundaire replica's.

Voor individuele en pooldatabases in Azure SQL Database kunt u uitschalen van leesbewerkingen in de Premium- of Bedrijfskritiek-servicelagen uitschakelen en opnieuw inschakelen met behulp van Azure Portal en Azure PowerShell. Deze opties zijn niet beschikbaar voor SQL Managed Instance omdat uitschalen met lezen niet kan worden uitgeschakeld.

Notitie

Voor individuele databases en elastische pooldatabases is de mogelijkheid om uitschalen van leesbewerkingen uit te schakelen voor achterwaartse compatibiliteit. Uitschalen van leesbewerkingen kan niet worden uitgeschakeld voor Bedrijfskritiek beheerde exemplaren.

Azure Portal

Voor Azure SQL Database kunt u de instelling voor uitschalen van leesbewerkingen beheren in het deelvenster Compute en opslagdatabase, beschikbaar onder Instellingen. Het gebruik van Azure Portal om uitschalen van leesbewerkingen in of uit te schakelen, is niet beschikbaar voor Azure SQL Managed Instance.

PowerShell

Belangrijk

De PowerShell Azure Resource Manager-module wordt nog steeds ondersteund, maar alle toekomstige ontwikkeling is voor de Az.Sql-module. De Azure Resource Manager-module blijft tot ten minste december 2020 bugfixes ontvangen. De argumenten voor de opdrachten in de Az-module en in de Azure Resource Manager-modules zijn aanzienlijk identiek. Zie Inleiding tot de nieuwe Azure PowerShell Az-module voor meer informatie over de compatibiliteit.

Voor het beheren van uitschalen van leesbewerkingen in Azure PowerShell is de Azure PowerShell-release van december 2016 of hoger vereist. Zie Azure PowerShell voor de nieuwste PowerShell-release.

In Azure SQL Database kunt u het uitschalen van leesbewerkingen in Azure PowerShell uitschakelen of opnieuw inschakelen door de set-AzSqlDatabase-cmdlet aan te roepen en de gewenste waarde (Enabled of Disabled) door te geven voor de -ReadScale parameter. Het uitschakelen van uitschalen van leesbewerkingen voor SQL Managed Instance is niet beschikbaar.

Als u het uitschalen van leesbewerkingen op een bestaande database wilt uitschakelen (waarbij u de items in de punthaken vervangt door de juiste waarden voor uw omgeving en de punthaken neerhalen):

Set-AzSqlDatabase -ResourceGroupName <resourceGroupName> -ServerName <serverName> -DatabaseName <databaseName> -ReadScale Disabled

Als u het uitschalen van leesbewerkingen op een nieuwe database wilt uitschakelen (vervang de items in de punthaken door de juiste waarden voor uw omgeving en laat u de punthaken vallen):

New-AzSqlDatabase -ResourceGroupName <resourceGroupName> -ServerName <serverName> -DatabaseName <databaseName> -ReadScale Disabled -Edition Premium

Als u het uitschalen van leesbewerkingen op een bestaande database opnieuw wilt inschakelen (vervang de items in de punthaken door de juiste waarden voor uw omgeving en laat u de punthaken vallen):

Set-AzSqlDatabase -ResourceGroupName <resourceGroupName> -ServerName <serverName> -DatabaseName <databaseName> -ReadScale Enabled

REST-API

Als u een database wilt maken waarvoor uitschalen voor lezen is uitgeschakeld of als u de instelling voor een bestaande database wilt wijzigen, gebruikt u de volgende methode waarbij de readScale eigenschap is ingesteld Enabled op of Disabled, zoals in de volgende voorbeeldaanvraag.

Method: PUT
URL: https://management.azure.com/subscriptions/{SubscriptionId}/resourceGroups/{GroupName}/providers/Microsoft.Sql/servers/{ServerName}/databases/{DatabaseName}?api-version= 2014-04-01-preview
Body: {
   "properties": {
      "readScale":"Disabled"
   }
}

Zie Databases - Maken of bijwerken voor meer informatie.

De tempdb database gebruiken op een alleen-lezen replica

De tempdb database op de primaire replica wordt niet gerepliceerd naar de alleen-lezen replica's. Elke replica heeft een eigen tempdb database die wordt gemaakt wanneer de replica wordt gemaakt. Dit zorgt ervoor dat tempdb deze kan worden bijgewerkt en kan worden gewijzigd tijdens de uitvoering van uw query. Als uw alleen-lezenworkload afhankelijk is van het gebruik van tempdb objecten, moet u deze objecten maken als onderdeel van dezelfde werkbelasting, terwijl u verbonden bent met een alleen-lezen replica.

Uitschalen van leesbewerkingen gebruiken met geo-gerepliceerde databases

Secundaire databases met geo-replicatie hebben dezelfde architectuur voor hoge beschikbaarheid als primaire databases. Als u verbinding maakt met de secundaire database met geografisch gerepliceerde secundaire database waarvoor uitschalen voor lezen is ingeschakeld, worden uw sessies doorgestuurd naar een van de replica's met ApplicationIntent=ReadOnly hoge beschikbaarheid op dezelfde manier als ze worden gerouteerd op de primaire schrijfbare database. De sessies zonder ApplicationIntent=ReadOnly worden doorgestuurd naar de primaire replica van de geo-gerepliceerde secundaire replica, die ook alleen-lezen is.

Op deze manier kan het maken van een geo-replica meerdere extra alleen-lezen replica's bieden voor een primaire database voor lezen/schrijven. Elke extra geo-replica biedt een andere set alleen-lezen replica's. Geo-replica's kunnen worden gemaakt in elke Azure-regio, inclusief de regio van de primaire database.

Notitie

Er is geen automatische round robin of een andere routering met gelijke taakverdeling tussen de replica's van een secundaire database met geo-replicatie, met uitzondering van een Hyperscale geo-replica met meer dan één HA-replica. In dat geval worden sessies met de intentie Alleen-lezen gedistribueerd over alle HA-replica's van een geo-replica.

Functieondersteuning voor alleen-lezen replica's

Een lijst met het gedrag van sommige functies op alleen-lezen replica's volgt:

• Controle op alleen-lezen replica's wordt automatisch ingeschakeld. Zie sql Database Audit Log Format voor meer informatie over de hiërarchie van de opslagmappen, naamconventies en logboekindeling.
• Query Performance Insight is afhankelijk van gegevens uit de Query Store, die momenteel geen activiteit bijhoudt op de alleen-lezen replica. Query Performance Insight toont geen query's die worden uitgevoerd op de alleen-lezen replica.
• Automatisch afstemmen is afhankelijk van de Query Store, zoals beschreven in het document Automatisch afstemmen. Automatisch afstemmen werkt alleen voor workloads die worden uitgevoerd op de primaire replica.

Volgende stappen

• Zie de Hyperscale-servicelaag van Hyperscale voor meer informatie over de aanbieding van SQL Database Hyperscale.