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 arkitekturen för hög tillgänglighet etableras varje enskild databas eller elastisk pooldatabas på tjänstnivån Premium och Affärskritisk automatiskt med en primär skrivskyddad replik och en eller flera sekundära skrivskyddade repliker. De sekundära replikerna etableras med samma beräkningsstorlek som den primära repliken. Med funktionen för utskalning av läsning kan du avlasta skrivskyddade arbetsbelastningar med hjälp av 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. På tjänstnivåerna Premium och Affärskritisk kan program få prestandafördelar med den här extra 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 hyperskalare med namnet repliker ger oberoende skalning, åtkomstisolering, arbetsbelastningsisolering, stöd för olika scenarier med lässkalning 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 tillgängliga på en sekundär HA-replik.

Arkitekturen med hög tillgänglighet för tjänstnivåerna 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. När du använder Azure SQL Database kan geo-repliker dock ge liknande funktioner på dessa tjänstnivåer. När du använder Azure SQL Managed Instance och redundansgrupper kan redundansgruppens skrivskyddade lyssnare tillhandahålla liknande funktioner.

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

Diagram showing readonly replicas.

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

Kommentar

Utskalning av läsning är alltid aktiverat på Affärskritisk tjänstnivå för SQL Managed Instance och för Hyperskala-databaser med minst en sekundär replik.

Om din SQL-anslutningssträng 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 ApplicationIntent inställningen i SQL-anslutningssträng, 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.

Kommentar

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

Datakonsekvens

Dataändringar som görs på den primära repliken sparas på skrivskyddade repliker synkront eller asynkront beroende på repliktyp. För alla repliktyper är dock läsningar från en skrivskyddad replik alltid asynkrona när det gäller den primära repliken. 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 återansluts kan den ansluta till en replik som är 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.

Vanliga svarstider för dataspridning mellan den primära repliken och skrivskyddade repliker varierar i intervallet från tiotals millisekunder till ensiffriga sekunder. Det finns dock ingen fast övre gräns för svarstid 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 incheckade data kan läsas omedelbart bör använda den primära repliken.

Kommentar

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 loggposten för transaktionsincheckning har tillämpats. När arbetsbelastningen använder större transaktioner ökar den effektiva svarstiden för dataspridning.

Information om hur du övervakar svarstiden för dataspridning finns i Övervaka och felsöka skrivskyddad replik.

Anslut till en skrivskyddad replik

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

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

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

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

Screenshot showing the SSMS Options button.

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

Screenshot showing SSMS Additional Connection Parameters.

Något av följande anslutningssträng ansluter klienten till en skrivskyddad replik (ersätter objekten i vinkelparenteserna med rätt värden för din miljö och släpper 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 skrivskyddad replik

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

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

Kommentar

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 skrivskyddade repliker.

Övervaka och felsöka skrivskyddade repliker

När du är ansluten till en skrivskyddad replik återspeglar dynamiska hanteringsvyer (DMV:er) replikens tillstånd och kan efterfrågas i övervaknings- och felsökningssyfte. 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:

Name Syfte
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 Tillhandahåller status och synkroniseringsstatistik för replikering. Gör om köstorleken och gör om frekvensen fungerar som indikatorer för svarstid 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 frå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 körningsplanen, inklusive körningsstatistik för en fråga.
sys.dm_io_virtual_file_stats() Tillhandahåller lagringsstatistik för IOPS, dataflöde och svarstid för alla databasfiler.

Kommentar

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

Övervaka skrivskyddade repliker med utökade händelser

Det går inte att skapa en utökad händelsesession när den är ansluten till en skrivskyddad replik. I Azure SQL Database skapas dock definitionerna av utökade händelsesessioner med databasomfattning som skapats och ändrats på den primära repliken till skrivskyddade repliker, inklusive geo-repliker, och avbildningshändelser på skrivskyddade repliker.

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

Följ dessa steg om du vill släppa 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 repliken, antingen genom att välja Stoppa session på sessionens snabbmeny i Object Explorer eller genom att ALTER EVENT SESSION [session-name-here] ON DATABASE STATE = STOP; köra i ett frågefönster.
  3. Anslut Object Explorer eller ett frågefönster till den primära repliken.
  4. Släpp sessionen på den primära repliken, antingen genom att välja Ta bort på snabbmenyn för sessionen eller genom att köra DROP EVENT SESSION [session-name-here] ON DATABASE;

Transaktionsisoleringsnivå på skrivskyddade repliker

Transaktioner på skrivskyddade repliker använder alltid transaktionsisoleringsnivån för ögonblicksbilder, oavsett sessionens transaktionsisoleringsnivå och oavsett eventuella frågetips. Ögonblicksbildisolering använder radversionshantering för att undvika blockeringsscenarier där läsare blockerar skrivare.

Om en ögonblicksbildisoleringstransaktion i sällsynta fall kommer åt 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. Detta är inte tillåtet, eftersom metadata saknar version. En samtidig uppdatering av metadata kan leda till inkonsekvens om den blandas med ögonblicksbildisolering."

Tidskrävande frå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 redundansmål (sekundära repliker i Premium- och Affärskritisk tjänstnivåer, Hyperskala HA-repliker och alla geo-repliker) skulle detta också fördröja databasåterställningen om en redundansväxling skulle inträffa, vilket orsakar längre avbrott ä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."

Kommentar

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.

Dricks

I premium- och Affärskritisk tjänstnivåer kan kolumnerna och i sys.dm_database_replica_states DMV användas för att övervaka datasynkroniseringsprocessen när de redo_queue_size redo_rate är anslutna till en skrivskyddad replik, vilket fungerar som indikatorer för dataspridningsfördröjning på den skrivskyddade repliken.

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

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

För SQL Database är lässkalning aktiverat 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.

Kommentar

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

Azure Portal

För Azure SQL Database kan du hantera inställningen för lässkalning i fönstret Beräkning + lagringsdatabas, som är tillgänglig 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

Viktigt!

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 cmdleten Set-AzSqlDatabase 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 readScale egenskapen 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ända databasen tempdb på en skrivskyddad replik

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

Använda 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 till en av replikerna med ApplicationIntent=ReadOnly 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 ytterligare skrivskyddade repliker för en primär databas med skrivskydd. 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.

Kommentar

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 skrivskyddad avsikt över alla HA-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 är automatiskt aktiverat på skrivskyddade repliker. 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 Automatisk justering. Automatisk justering fungerar endast för arbetsbelastningar som körs på den primära repliken.

Nästa steg

  • Information om SQL Database Hyperscale-erbjudandet finns i Tjänstnivån Hyperskala.