Använda skrivskyddade repliker för att avlasta skrivskyddade frågearbetsbelastningar

GÄLLER FÖR: Azure SQL Database Azure SQL Managed Instance

Som en del av arkitekturen för hög tillgänglighet etableras varje enskild databas, elastisk pooldatabas och hanterad instans på tjänstnivån Premium och Affärskritisk automatiskt med en primär skrivskyddad replik och flera sekundära skrivskyddade repliker. De sekundära replikerna etableras med samma beräkningsstorlek som den primära repliken. Med funktionen för lässkalning kan du avlasta skrivskyddade arbetsbelastningar med beräkningskapaciteten för en av de skrivskyddade replikerna, i stället för att köra dem på skrivskyddad replik. På så sätt kan vissa skrivskyddade arbetsbelastningar isoleras från skrivskyddade arbetsbelastningar och påverkar inte deras prestanda. Funktionen är avsedd för program som innehåller logiskt avgränsade skrivskyddade arbetsbelastningar, till exempel analys. I Premium och Affärskritisk kan program få prestandafördelar genom att använda den här ytterligare kapaciteten utan extra kostnad.

Funktionen för utskalning av läsning är också tillgänglig på tjänstnivån Hyperskala när minst en sekundär replik läggs till. Sekundära repliker i hyperskala ger oberoende skalning, åtkomstisolering, arbetsbelastningsisolering, massiv utskalning av läsning och andra fördelar. Flera sekundära HA-repliker kan användas för belastningsutjämning av skrivskyddade arbetsbelastningar som kräver fler resurser än vad som är tillgängligt på en sekundär HA-replik.

Arkitekturen för hög tillgänglighet i tjänstnivån Basic, Standard och Generell användning omfattar inte några repliker. Funktionen för utskalning av läsning är inte tillgänglig på dessa tjänstnivåer. Geo-repliker kan dock ge liknande funktioner på dessa tjänstnivåer.

Följande diagram illustrerar funktionen för att Premium och Affärskritisk databaser och hanterade instanser.

Funktionen för utskalning av läsning är aktiverad som standard på nya Premium, Affärskritisk och Hyperskala databaser.

Om SQL har konfigurerats med omdirigeras programmet till en skrivskyddad replik av databasen eller ApplicationIntent=ReadOnly den hanterade instansen. Information om hur du använder egenskapen ApplicationIntent finns i Ange program avsikt.

Om du vill säkerställa att programmet ansluter till den primära repliken oavsett inställningen i SQL-anslutningssträngen måste du uttryckligen inaktivera lässkalning när du skapar databasen eller när du ändrar dess ApplicationIntent konfiguration. Om du till exempel uppgraderar databasen från Standard- eller Generell användning-nivån till Premium eller Affärskritisk och vill se till att alla dina anslutningar fortsätter att gå till den primära repliken inaktiverar du lässkalning. Mer information om hur du inaktiverar det finns i Aktivera och inaktivera lässkalning.

Datakonsekvens

Dataändringar som görs på den primära repliken sprids till skrivskyddade repliker asynkront. Inom en session som är ansluten till en skrivskyddade replik är läsningar alltid transaktionellt konsekventa. Men eftersom dataspridningsfördröjningen varierar kan olika repliker returnera data vid något olika tidpunkter i förhållande till den primära och varandra. Om en skrivskyddade replik blir otillgänglig och sessionen återansluter kan den ansluta till en replik som är vid en annan tidpunkt än den ursprungliga repliken. Om ett program på samma sätt ändrar data med hjälp av en läs/skriv-session och läser den direkt med hjälp av en skrivskyddade session, är det möjligt att de senaste ändringarna inte visas omedelbart på den skrivskyddade repliken.

Svarstiden för dataspridning mellan den primära repliken och skrivskyddade repliker varierar mellan tiotals millisekunder och ensiffriga sekunder. Det finns dock ingen fast övre gräns för svarstiden för dataspridning. Villkor som hög resursanvändning på repliken kan öka svarstiden avsevärt. Program som kräver garanterad datakonsekvens mellan sessioner eller kräver att inlästa data ska vara läsbara omedelbart bör använda den primära repliken.

Anslut till en skrivskyddade replik

När du aktiverar lässkalning för en databas avgör alternativet i anslutningssträngen som tillhandahålls av klienten om anslutningen dirigeras till skrivrepliken eller till en ApplicationIntent skrivskyddad replik. Mer specifikt, ApplicationIntent om värdet är ReadWrite (standardvärdet) dirigeras anslutningen till skrivskyddade repliken. Detta är identiskt med beteendet när ApplicationIntent inte ingår i anslutningssträngen. Om ApplicationIntent värdet är ReadOnly dirigeras anslutningen till en skrivskyddad replik.

Följande anslutningssträng ansluter till exempel klienten till en skrivskyddat replik (ersätt objekten i vinkelparenteserna med rätt värden för din miljö och släppa vinkelparenteserna):

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

Någon av följande anslutningssträngar ansluter klienten till en skrivskyddade replik (ersätt objekten i vinkelparenteserna med rätt värden för din miljö och ta bort vinkelparenteserna):

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;

Kontrollera att en anslutning är till en skrivskyddade replik

Du kan kontrollera om du är ansluten till en skrivskyddad replik genom att köra följande fråga i kontexten för din databas. Den returnerar READ_ONLY när du är ansluten till en skrivskyddade replik.

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

Övervakning och felsökning av skrivskyddade repliker

När du är ansluten till en skrivskyddad replik återspeglar dynamiska hanteringsvyer (DMV: er) replikens tillstånd och kan efterfrågas för övervakning och felsökning. Databasmotorn innehåller flera vyer för att exponera en mängd olika övervakningsdata.

Följande vyer används ofta för övervakning och felsökning av repliker:

Övervaka skrivskyddade repliker med Extended Events

En utökad händelsesession kan inte skapas när du är ansluten till en skrivskyddad replik. Men i Azure SQL Database har definitionerna av utökade händelsesessioner med databasomfång skapats och ändrats på den primära repliken till skrivskyddade repliker, inklusive geo-repliker, och avbildar händelser på skrivskyddade repliker.

En utökad händelsesession på en skrivskyddade replik som baseras på en sessionsdefinition från den primära repliken kan startas och stoppas oberoende av den primära repliken. När en utökad händelsesession tas bort på den primära repliken tas den även bort på alla skrivskyddade repliker.

Transaktionsisoleringsnivå på skrivskyddade repliker

Frågor som körs på skrivskyddade repliker mappas alltid till transaktionsisoleringsnivån för ögonblicksbilder. Ögonblicksbildisolering använder radversionshantering för att undvika blockeringsscenarier där läsarna blockerar skrivare.

Om en transaktion för ögonblicksbildisolering i sällsynta fall får åtkomst till objektmetadata som har ändrats i en annan samtidig transaktion, kan den få felet 3961, "Transaktionen för ögonblicksbildisolering misslyckades i databasen %.*ls" eftersom objektet som används av -instruktionen har ändrats av en DDL-instruktion i en annan samtidig transaktion sedan transaktionen började. Detta är inte tillåtet, eftersom metadata saknar version. En samtidig uppdatering av metadata kan leda till inkonsekvens om den blandas med ögonblicksbildisolering."

Långvariga frågor på skrivskyddade repliker

Frågor som körs på skrivskyddade repliker behöver åtkomst till metadata för de objekt som refereras i frågan (tabeller, index, statistik osv.) I sällsynta fall, om objektmetadata ändras på den primära repliken medan en fråga har ett lås på samma objekt på den skrivskyddade repliken, kan frågan blockera processen som tillämpar ändringar från den primära repliken till den skrivskyddade repliken. Om en sådan fråga skulle köras under en längre tid skulle det leda till att den skrivskyddade repliken inte är synkroniserad med den primära repliken. För repliker som är potentiella redundansmål (sekundära repliker i tjänstnivåer för Premium och Affärskritisk, hyperskala-HA-repliker och alla geo-repliker) skulle detta också fördröja databasåterställningen om en redundans skulle inträffa, vilket orsakar längre stilleståndstid än förväntat.

Om en långvarig fråga på en skrivskyddad replik direkt eller indirekt orsakar den här typen av blockering kan den avslutas automatiskt för att undvika överdriven datasvarstid och potentiell påverkan på databasens tillgänglighet. Sessionen får felmeddelande 1219, "Sessionen har kopplats från på grund av en DDL-åtgärd med hög prioritet", eller fel 3947, "Transaktionen avbröts eftersom den sekundära beräkningen inte kunde komma ikapp. Försök att utföra transaktionen igen."

Aktivera och inaktivera lässkalning

Lässkalning är aktiverat som standard på tjänstnivåer Premium, Affärskritisk hyperskala och hyperskala. Läsutskalning kan inte aktiveras på tjänstnivåerna Basic, Standard Generell användning eller standard. Lässkalning inaktiveras automatiskt på hyperskaladatabaser som konfigurerats med noll sekundära repliker.

Du kan inaktivera och återaktivera lässkalning för enkla databaser och elastiska pooldatabaser på Premium eller Affärskritisk-tjänstnivåer med hjälp av följande metoder.

Azure Portal

Du kan hantera lässkalningsinställningen på bladet Konfigurera databas.

PowerShell

Hantering av läsutskalning i Azure PowerShell kräver versionen från december 2016 Azure PowerShell eller nyare. Den senaste Versionen av PowerShell finns i Azure PowerShell.

Du kan inaktivera eller återaktivera lässkalning i Azure PowerShell genom att aktivera cmdleten Set-AzSqlDatabase och skicka det önskade värdet ( Enabled eller ) för Disabled -ReadScale parametern .

Inaktivera lässkalning på en befintlig databas (ersätt objekten i vinkelparenteserna med rätt värden för din miljö och ta bort vinkelparenteserna):

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

Inaktivera lässkalning på en ny databas (ersätt objekten i vinkelparenteserna med rätt värden för din miljö och ta bort vinkelparenteserna):

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

Återaktivera lässkalning på en befintlig databas (ersätt objekten i vinkelparenteserna med rätt värden för din miljö och släppa vinkelparenteserna):

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

REST API

Om du vill skapa en databas med lässkalning inaktiverad, eller om du vill ändra inställningen för en befintlig databas, använder du följande metod med egenskapen inställd på eller , som i readScale Enabled följande Disabled exempelbegäran.

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"
   }
}

Mer information finns i Databaser – Skapa eller uppdatera.

Använda tempdb databasen på en skrivskyddade replik

Databasen tempdb på den primära repliken replikeras inte till de skrivskyddade replikerna. Varje replik har en tempdb egen databas som skapas när repliken skapas. Detta säkerställer tempdb att är uppdateringsbar och kan ändras under frågekörningen. Om din skrivskyddade arbetsbelastning är beroende av att använda objekt bör du skapa dessa objekt som en del av samma arbetsbelastning när du är ansluten tempdb till en skrivskyddade replik.

Använda lässkalning med geo-replikerade databaser

Geo-replikerade sekundära databaser har samma arkitektur för hög tillgänglighet som primära databaser. Om du ansluter till den geo-replikerade sekundära databasen med lässkalning aktiverat dirigeras dina sessioner med till en av replikerna med hög tillgänglighet på samma sätt som de dirigeras på den primära ApplicationIntent=ReadOnly skrivbara databasen. Sessionerna utan ApplicationIntent=ReadOnly dirigeras till den primära repliken av den geo-replikerade sekundära repliken, som också är skrivskyddad.

På så sätt kan skapandet av en geo-replik ge flera ytterligare skrivskyddade repliker för en primär skrivskyddade databas. Varje ytterligare geo-replik ger en annan uppsättning skrivskyddade repliker. Georepliker kan skapas i valfri Azure-region, inklusive den primära databasens region.

Funktionsstöd på skrivskyddade repliker

En lista över beteendet för vissa funktioner på skrivskyddade repliker finns nedan:

• Granskning av skrivskyddade repliker aktiveras automatiskt. Mer information om hierarkin för lagringsmappar, namngivningskonventioner och loggformat finns i SQL Database Granskningsloggformat.
• Query Performance Insight förlitar sig på data från Query Store, som för närvarande inte spårar aktivitet på den skrivskyddade repliken. Query Performance Insight visar inte frågor som körs på den skrivskyddade repliken.
• Automatisk justering förlitar sig på Query Store, enligt beskrivningen i dokumentet om automatisk justering. Automatisk justering fungerar bara för arbetsbelastningar som körs på den primära repliken.

Nästa steg

• Information om hur SQL Database hyperskala finns i Tjänstnivå för hyperskala.