Dela via

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

  • Artikel

gäller för:Azure SQL DatabaseAzure SQL Managed Instance

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

Funktionen skala ut är också tillgänglig i Hyperskala-tjänstnivån när det läggs till minst en sekundär replik. Hyperskala sekundära namngivna repliker tillhandahåller oberoende skalning, åtkomstisolering, arbetsbelastningsisolering, stöd för olika läs-skalningsscenarier och andra fördelar. Flera sekundära HA-repliker kan användas för lastbalansering av skrivskyddade arbetslaster som kräver fler resurser än vad som finns tillgängliga på en sekundär HA-replik.

Arkitekturen för hög tillgänglighet för tjänstnivåerna Basic, Standard och Generell användning innehåller inga repliker. Funktionen för avläsning av skalning är inte tillgänglig på dessa tjänstnivåer. Men när du använder Azure SQL Database kan geo-repliker tillhandahålla liknande funktioner på dessa tjänstnivåer. När du använder Azure SQL Managed Instance och redundansgrupper kan den skrivskyddade lyssnaren för redundansgruppen erbjuda liknande funktionalitet.

Följande diagram illustrerar funktionen för Premium- och affärskritiska databaser och hanterade instanser.

diagram som visar skrivskyddade repliker.

Funktionen läsa utökning är som standard aktiverad i nya Premium-, Business Critical- och Hyperskale-databaser.

Not

Utskalning för läsoperationer är alltid aktiverat på tjänstnivån Business Critical i SQL Managed Instance och för Hyperscale-databaser med minst en sekundär kopia.

Om sql-anslutningssträngen har konfigurerats med ApplicationIntent=ReadOnlyomdirigeras programmet till en skrivskyddad replik av databasen eller den hanterade instansen. Information om hur du använder egenskapen ApplicationIntent finns i Ange program avsikt.

Endast för Azure SQL Database, om du vill se till att programmet ansluter till den primära repliken oavsett inställningen ApplicationIntent i SQL-anslutningssträngen, måste du uttryckligen inaktivera utskalning av läsning när du skapar databasen eller när du ändrar dess konfiguration. Om du till exempel uppgraderar databasen från standard- eller generell användningsnivå till Premium eller Affärskritisk och vill se till att alla dina anslutningar fortsätter att gå till den primära repliken inaktiverar du utskalning av läsning. Mer information om hur du inaktiverar det finns i Aktivera och inaktivera lässkalning.

Not

Query Store- och SQL Profiler-funktioner stöds inte på skrivskyddade repliker.

Datakonsekvens

Dataförändringar som görs på den primära repliken sparas på skrivskyddade repliker synkront eller asynkront beroende på typen av replik. För alla repliktyper är dock läsningar från en skrivskyddad replik alltid asynkrona i förhållande till den primära. I en session som är ansluten till en skrivskyddad replik är läsningar alltid transaktionsmässigt konsekventa. Eftersom svarstiden för dataspridning är variabel kan olika repliker returnera data vid något olika tidpunkter i förhållande till den primära och varandra. Om en skrivskyddad replik blir otillgänglig, och en session återansluter, kan den ansluta till en replik som befinner sig vid en annan tidpunkt än den ursprungliga repliken. På samma sätt, om ett program ändrar data med hjälp av en skrivskyddad session i den primära och omedelbart läser den med hjälp av en skrivskyddad session på en skrivskyddad replik, är det möjligt att de senaste ändringarna inte visas omedelbart.

Typisk fördröjning vid dataspridning mellan den primära repliken och läsreplikerna varierar från tiotals millisekunder till ensiffriga sekunder. Det finns dock ingen fast övre gräns för svarstid för dataspridning. Faktorer som hög resursanvändning på repliken kan öka latensen avsevärt. Program som kräver garanterad datakonsekvens mellan sessioner eller kräver att incheckade data kan läsas omedelbart bör använda den primära repliken.

Not

Svarstid för dataspridning omfattar den tid som krävs för att skicka och spara (om tillämpligt) loggposter till en sekundär replik. Den innehåller också den tid som krävs för att göra om (tillämpa) dessa loggposter på datasidor. För att säkerställa datakonsekvens visas inte ändringarna förrän transaktionsloggen har tillämpats. När arbetsbelastningen använder större transaktioner ökar den effektiva svarstiden för dataspridning.

För att övervaka latensen för dataspridning, se Övervaka och felsöka skrivskyddade replika.

Ansluta till en skrivskyddad replik

När du aktiverar utskalning av läsning för en databas avgör alternativet ApplicationIntent i anslutningssträngen som tillhandahålls av klienten om anslutningen dirigeras till skrivrepliken eller till en skrivskyddad replik. Specifikt, om ApplicationIntent värde är ReadWrite (standardvärdet) dirigeras anslutningen till läsa-skriva-replikan. Detta är identiskt med beteendet när ApplicationIntent inte ingår i anslutningssträngen. Om ApplicationIntent värdet är ReadOnlydirigeras anslutningen till en skrivskyddad replik.

Följande anslutningssträng ansluter till exempel klienten till en skrivskyddad replik (genom att ersätta 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=ReadOnly;User ID=<myLogin>;Password=<password>;Trusted_Connection=False; Encrypt=True;

Om du vill ansluta till en skrivskyddad replik med SQL Server Management Studio (SSMS) väljer du Alternativ

Skärmbild som visar knappen SSMS-alternativ.

Välj Ytterligare anslutningsparametrar och ange ApplicationIntent=ReadOnly och välj sedan Anslut

skärmbild som visar ytterligare SSMS-anslutningsparametrar.

Vilken som helst av följande anslutningssträngar ansluter klienten till en skriv-läsbar 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=<password>;Trusted_Connection=False; Encrypt=True;

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

Kontrollera att anslutningen går till en skrivskyddad replik

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

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

Notera

I tjänstnivåerna Premium och Affärskritisk är endast en av de skrivskyddade replikerna tillgänglig vid en viss tidpunkt. Hyperskala stöder flera läs-skyddade repliker.

Övervaka och felsöka skrivskyddade repliker

Du har en mängd olika sätt att övervaka skrivskyddade repliker, till exempel: DMV:er, utökade händelser och databasbevakare (förhandsversion).

När du är ansluten till en skrivskyddad replik återspeglar dynamiska hanteringsvyer (DMV:er) replikens tillstånd och kan användas 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 replikövervakning och felsökning:

Namn Avsikt
sys.dm_db_resource_stats Tillhandahåller resursanvändningsmått för den senaste timmen, inklusive PROCESSOR, data-I/O och loggskrivningsanvändning i förhållande till tjänstmålsgränser.
sys.dm_os_wait_stats Innehåller sammanställd väntestatistik för databasmotorinstansen.
sys.dm_database_replica_states Anser status för replikors hälsa och synkroniseringsstatistik. Redo-köns storlek och redo-hastighet fungerar som indikatorer på latens för dataspridning på den skrivskyddade repliken.
sys.dm_os_performance_counters Tillhandahåller prestandaräknare för databasmotorn.
sys.dm_exec_query_stats Tillhandahåller körningsstatistik per sökfråga, till exempel antal körningar, CPU-tid som används osv.
sys.dm_exec_query_plan() Tillhandahåller cachelagrade frågeplaner.
sys.dm_exec_sql_text() Tillhandahåller frågetext för en cachelagrad frågeplan.
sys.dm_exec_query_profiles Ger frågeförlopp i realtid medan frågor körs.
sys.dm_exec_query_plan_stats() Innehåller den senast kända faktiska exekveringsplanen, inklusive körningsstatistik för en sökfråga.
sys.dm_io_virtual_file_stats() Tillhandahåller lagringsstatistik för IOPS, dataflöde och svarstid för alla databasfiler.

Not

sys.resource_stats och sys.elastic_pool_resource_stats DMV:er i den logiska master-databasen returnerar resursanvändningsdata för den primära repliken.

Övervaka skrivskyddade repliker (read-only replicas) med Extended Events

Det går inte att skapa en utökad händelsesession när den är ansluten till en skrivskyddad replik. Men i Azure SQL Database och Azure SQL Managed Instance replikeras definitionerna av databasomfattande extended event sessioner som skapats och ändrats på den primära repliken till skrivskyddade repliker, inklusive geo-repliker, och avbilda händelser på skrivskyddade repliker.

I Azure SQL Database kan en utökad händelsesession på en skrivskyddad replik som baseras på en sessionsdefinition från den primära repliken startas och stoppas oberoende av sessionen på den primära repliken.

Om du vill starta en spårning på en skrivskyddad replik i Azure SQL Managed Instance måste du först starta spårningen på den primära repliken innan du kan starta spårningen på den skrivskyddade repliken. Om du inte först startar spårningen på den primära repliken kommer du att få följande felmeddelande när du försöker starta spårningen på den skrivskyddade repliken:

Msg 3906, Nivå 16, Delstat 2, Rad 1 Det gick inte att uppdatera databasen "master" eftersom den är skrivskyddad.

När du har startat spårningen först på den primära repliken och sedan på den skrivskyddade repliken kan du stoppa spårningen på den primära repliken.

Följ dessa steg för att ta bort en händelsesession på en skrivskyddad replik.

  1. Anslut SSMS Object Explorer eller ett frågefönster till den skrivskyddade repliken.
  2. Stoppa sessionen på den skrivskyddade replikan antingen genom att välja Stoppa session i snabbmenyn för sessionen i Object Explorer eller genom att köra ALTER EVENT SESSION [session-name-here] ON DATABASE STATE = STOP; i ett queryfönster.
  3. Anslut Object Explorer eller ett frågefönster till den primära repliken.
  4. Avsluta sessionen på den primära replikan genom att välja Ta bort på sessionens snabbmeny eller genom att köra DROP EVENT SESSION [session-name-here] ON DATABASE;

Transaktionsisoleringsnivå på skrivskyddade repliker

Transaktioner på skrivskyddade repliker använder alltid ögonblicksbild för transaktionsisoleringsnivå, oavsett transaktionsisoleringsnivån för sessionen och oavsett några frågeledtrådar. Ögonblicksbildisolering använder radversionshantering för att undvika blockeringsscenarier där läsare blockerar skrivare.

Om en ögonblicksbildisoleringstransaktion i sällsynta fall får åtkomst till objektmetadata som har ändrats i en annan samtidig transaktion kan det få fel 3961, "Ögonblicksbildisoleringstransaktionen misslyckades i databasen "%.*ls" eftersom objektet som används av -instruktionen har ändrats av en DDL-instruktion i en annan samtidig transaktion sedan transaktionen startades. Det är inte tillåtet eftersom metadata inte är versioniserade. En samtidig uppdatering av metadata kan leda till inkonsekvens om den blandas med ögonblicksbildisolering."

Långvariga sökfrågor på skrivskyddade repliker

Frågor som körs på skrivskyddade repliker måste komma åt 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 på den skrivskyddade repliken. Om en sådan fråga skulle köras under en längre tid skulle den skrivskyddade repliken vara betydligt osynkroniserad med den primära repliken. För repliker som är potentiella failovermål (sekundära repliker i premium- och affärskritiska tjänstnivåer, Hyperskala HA-repliker och alla geo-repliker) skulle detta också fördröja databasåterställningen om en failover skulle inträffa, vilket orsakar längre avbrottstid ä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 datafördröjning och potentiell påverkan på databastillgängligheten. Sessionen får fel 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 om. Försök igen med transaktionen."

Not

Om du får fel 3961, 1219 eller 3947 när du kör frågor mot en skrivskyddad replik kan du försöka med frågan igen. Du kan också undvika åtgärder som ändrar objektmetadata (schemaändringar, indexunderhåll, statistikuppdateringar osv.) på den primära repliken medan långvariga frågor körs på sekundära repliker.

Tips

När du är ansluten till en skrivskyddad replik i premium- och affärskritiska tjänstnivåer kan kolumnerna redo_queue_size och redo_rate i sys.dm_database_replica_states DMV användas för att övervaka datasynkroniseringsprocessen, vilket fungerar som indikatorer på svarstid för dataspridning på den skrivskyddade repliken.

Aktivera och inaktivera utskalning av läsning för SQL Database

För SQL Managed Instance aktiveras utökad läsning automatiskt på tjänstnivån Affärskritisk och är inte tillgänglig på tjänstnivån Allmän. Det går inte att inaktivera och återaktivera utskalning av läsning.

För SQL Database aktiveras lässkalning som standard på tjänstnivåerna Premium, Affärskritisk och Hyperskala. Utskalning av läsning kan inte aktiveras på tjänstnivåerna Basic, Standard eller Generell användning. Utskalning av läsning inaktiveras automatiskt på Hyperskala-databaser som konfigurerats med noll sekundära repliker.

För enkla databaser och pooldatabaser i Azure SQL Database kan du inaktivera och återaktivera lässkalning på tjänstnivåerna Premium eller Affärskritisk med hjälp av Azure-portalen och Azure PowerShell. De här alternativen är inte tillgängliga för SQL Managed Instance eftersom utskalning av läsning inte kan inaktiveras.

Not

För enkla databaser och elastiska pooldatabaser finns möjligheten att inaktivera utskalning av läsning för bakåtkompatibilitet. Utskalning av läsning kan inte inaktiveras på affärskritiska hanterade instanser.

Azure-portalen

För Azure SQL Database kan du hantera inställningen för lässkalning i fönstret Beräkning + lagring för databaser, som finns under Inställningar. Att använda Azure-portalen för att aktivera eller inaktivera utskalning av läsning är inte tillgängligt för Azure SQL Managed Instance.

PowerShell

Viktig

PowerShell Azure Resource Manager-modulen stöds fortfarande, men all framtida utveckling gäller för Az.Sql-modulen. Azure Resource Manager-modulen fortsätter att ta emot felkorrigeringar fram till åtminstone december 2020. Argumenten för kommandona i Az-modulen och i Azure Resource Manager-modulerna är i stort sätt identiska. Mer information om deras kompatibilitet finns i Introduktion till den nya Azure PowerShell Az-modulen.

För att hantera lässkalning i Azure PowerShell krävs Azure PowerShell-versionen från december 2016 eller senare. Den senaste PowerShell-versionen finns i Azure PowerShell.

I Azure SQL Database kan du inaktivera eller återaktivera lässkalning i Azure PowerShell genom att anropa Set-AzSqlDatabase cmdlet och skicka in önskat värde (Enabled eller Disabled) för parametern -ReadScale. Det är inte tillgängligt att inaktivera utskalning av läsning för SQL Managed Instance.

Så här inaktiverar du utskalning av läsning i en befintlig databas (ersätter objekten i vinkelparenteserna med rätt värden för din miljö och släpper vinkelparenteserna):

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

Så här inaktiverar du utskalning av läsning på en ny databas (ersätter objekten i vinkelparenteserna med rätt värden för din miljö och släpper vinkelparenteserna):

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

Om du vill återaktivera lässkalning på en befintlig databas (ersätta 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 ändra inställningen för en befintlig databas använder du följande metod med egenskapen readScale inställd på Enabled eller Disabled, som i följande 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änd tempdb-databasen på en skrivskyddad replik

Den tempdb databasen på den primära repliken replikeras inte till läsbara repliker. Varje replik har en egen tempdb databas som skapas när repliken skapas. Detta säkerställer att tempdb kan uppdateras och ändras under körningen av din fråga. Om din skrivskyddade arbetsbelastning är beroende av att använda tempdb-objekt bör du skapa dessa objekt som en del av samma arbetsbelastning när du är ansluten till en skrivskyddad replikering.

Använd lässkalning med geo-replikerade databaser

Geo-replikerade sekundära databaser har samma arkitektur med 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 ApplicationIntent=ReadOnly till en av replikerna med hög tillgänglighet på samma sätt som de dirigeras till den primära skrivbara databasen. Sessioner utan ApplicationIntent=ReadOnly dirigeras till den primära repliken av den geo-replikerade sekundära, som också är skrivskyddad.

På så sätt kan skapandet av en geo-replik ge flera skrivskyddade repliker för en primär databas med läs- och skrivåtkomst. Varje ytterligare geo-replik innehåller en annan uppsättning skrivskyddade repliker. Geo-repliker kan skapas i valfri Azure-region, inklusive den primära databasens region.

Not

Det finns ingen automatisk resursallokering eller någon annan belastningsutjämnad routning mellan replikerna i en geo-replikerad sekundär databas, med undantag för en Hyperskala-geo-replik med mer än en HA-replik. I så fall distribueras sessioner med avsikt att endast läsa över alla hög tillgänglighet-repliker av en geo-replik.

Funktionsstöd för skrivskyddade repliker

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

  • Granskning av skrivskyddade repliker aktiveras automatiskt. Mer information om hierarkin för lagringsmappar, namngivningskonventioner och loggformat finns i SQL Database Audit Log Format.
  • 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ågeställningar 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 endast för arbetsbelastningar som körs på den primära repliken.

Nästa steg