Fastställ varför ändringar från primär replika inte återspeglas på sekundär replika för en Always On-tillgänglighetsgrupp

Gäller för:SQL Server

Klientapplikationen genomför en uppdatering av den primära repliken framgångsrikt, men en förfrågan om sekundärkopian visar att ändringen inte återspeglas. Detta fall antar att din tillgänglighet har ett hälsosamt synkroniseringstillstånd. I de flesta fall försvinner detta beteende efter några minuter.

Om ändringar fortfarande inte återspeglas på sekundärkopian efter några minuter kan det uppstå en flaskhals i synkroniseringsarbetsflödet. Var flaskhalsen finns beror på om den sekundära replikan är konfigurerad för synkron eller asynkron commit.

synkron kommittering

Varje lyckad uppdatering på primärkopian har redan synkroniserats med sekundärkopian, eller så har loggposterna redan rensats för härdning på sekundärkopian. Därför bör flaskhalsen finnas i redo-processen som sker efter att loggen har tömts på den sekundära repliken.

När redo väl har hunnit ikapp använder alla läsarbetsbelastningar på den sekundära repliken snapshot-isolering:

  • Långvariga transaktioner på primärkopian

  • Gör om på sekundär replika

asynkron kommittering

Eftersom asynkron incheckning bekräftar en transaktion så snart den har skrivits till den lokala disken, kan flaskhalsen finnas var som helst efter den punkten:

  • Långvariga transaktioner på primärkopian

  • Nätverkslatens eller genomströmning

  • Loggskrivning på den sekundära repliken

  • Gör om på sekundärkopian

Följande avsnitt beskriver de vanligaste orsakerna till att ändringar på primärrepliken inte återspeglas i sekundärrepliken vid skrivskyddade frågor.

Långvariga aktiva transaktioner

En långvarig transaktion på primärkopian förhindrar att uppdateringarna läses på sekundärkopian.

Explanation

Alla läsarbetsbelastningar på den sekundära repliken är snapshot isolation-frågor. Vid snapshot-isolering ser skrivskyddade klienter tillgänglighetsdatabasen på den sekundära repliken vid början av den äldsta aktiva transaktionen i den omgjorda loggen. Om en transaktion inte har slutförts på flera timmar blockerar den öppna transaktionen alla frågor med endast läsåtkomst från att se några nya ändringar.

Diagnos och lösning

På den primära repliken använder du DBCC OPENTRAN (Transact-SQL) för att visa de äldsta aktiva transaktionerna och kontrollera om de kan rullas tillbaka. När de äldsta aktiva transaktionerna rullas tillbaka och synkroniseras till den sekundära repliken kan läsarbetsbelastningar på den sekundära repliken se uppdateringar i tillgänglighetsdatabasen fram till början av den då äldsta aktiva transaktionen.

Hög nätverkslatens eller låg nätverksgenomströmning orsakar logguppbyggnad på primär replik

Hög nätverkslatens eller låg genomströmning kan förhindra att loggar skickas till den sekundära repliken tillräckligt snabbt.

Explanation

Den primära repliken aktiverar flödeskontrollen på loggsändningen när den har överskridit det maximalt tillåtna antalet icke-bekräftade meddelanden som skickas till den sekundära repliken. Tills några av dessa meddelanden har bekräftats kan inga fler loggblock skickas till den sekundära repliken. Denna situation kan ha en allvarligare inverkan på potentiell dataförlust och potentiellt äventyra ditt återställningspunktmål (RPO).

Diagnos och lösning

Ett högt DMV-värde log_send_queue_size kan indikera att loggar hålls tillbaka vid primärreplikan. Att dividera detta värde med log_send_rate kan ge dig en grov uppskattning av hur snart data kan komma ikapp på sekundärkopian.

Det är också användbart att kontrollera de två prestandaobjekten SQL Server:Availability Replica > Flow Control Time (ms/sec) och SQL Server:Availability Replica > Flow control/sec. Att multiplicera dessa två värden visar i sista sekunden hur mycket tid som lagts på att vänta på att flow control skulle rensas. Ju längre väntetid för flödeskontroll, desto lägre sändningshastighet.

Nedan följer en lista över användbara mätvärden för att diagnostisera nätverkslatens och genomströmning. Du kan använda andra Windows verktyg som ping.exe för att utvärdera nätverksanvändning.

  • DMV log_send_queue_size

  • DMV log_send_rate

  • Prestandaräknare SQL Server:Database > Log Bytes Flushed/sec

  • Prestandaräknare SQL Server:Database Mirroring > Send/Receive Ack Time

  • Prestandaräknare SQL Server:Availability Replica > Bytes Sent to Replica/sec

  • Prestandaräknare SQL Server:Availability Replica > Bytes Sent to Transport/sec

  • Prestandaräknare SQL Server:Availability Replica > Flow Control Time (ms/sec)

  • Prestandaräknare SQL Server:Availability Replica > Flow Control/sec

  • Prestandaräknare SQL Server:Availability Replica > Resent Messages/sec

För att åtgärda detta problem, försök uppgradera din nätverksbandbredd eller ta bort eller minska onödig nätverkstrafik.

En annan rapporteringsarbetsbelastning hindrar redo-tråden från att köras

Redo-tråden på den sekundära repliken blockeras från att göra ändringar i datadefinitionsspråket (DDL) av en långvarig skrivskyddad fråga. Redo-tråden måste avblockeras innan den kan göra ytterligare uppdateringar tillgängliga för läsarbetslaster.

Explanation

På den sekundära replikan tar de skrivskyddade frågorna schemastabilitetslås (Sch-S). Dessa Sch-S lås kan hindra redo-tråden från att ta schemamodifieringslås (Sch-M) för att göra DDL-ändringar. En blockerad redo-tråd kan inte bearbeta loggposter förrän den har avblockerats.

Diagnos och lösning

När redo-tråden blockeras genereras en utökad händelse som anropas sqlserver.lock_redo_blocked . Dessutom kan du fråga DMV:s sys.dm_exec_request på den sekundära repliken för att ta reda på vilken session som blockerar REDO-tråden, och sedan kan du vidta korrigerande åtgärder. Följande fråga returnerar sessions-ID:t för den rapporteringsarbetsbelastning som blockerar redo-tråden.

select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource   
from sys.dm_exec_requests where command = 'DB STARTUP'

Du kan låta rapporteringsarbetsbelastningen avslutas, varpå redo-tråden avblockeras, eller så kan du avblockera redo-tråden omedelbart genom att köra KILL (Transact-SQL) kommandot på blocksessionens ID.

Redo-tråden halkar efter på grund av konkurrens om resurser

En hög rapporteringsbelastning på sekundärkopian har försämrat prestandan för sekundärkopian, och redo-tråden har halkat efter.

Explanation

När loggposter appliceras på den sekundära repliken läser redo-tråden loggposterna från loggdisken, och för varje loggpost går den sedan åt datasidorna för att applicera loggposten. Sidåtkomsten kan vara I/O-begränsad (åtkomst till den fysiska disken) om sidan inte redan finns i buffertpoolen. Om det finns en rapporteringsarbetsbelastning som är I/O-bunden konkurrerar rapporteringsarbetsbelastningen om I/O-resurser med redo-tråden och kan fördröja redo-tråden. Denna situation hindrar inte bara andra rapporteringsarbetsbelastningar från att se uppdaterade data, utan påverkar även RTO.

Diagnos och lösning

Du kan använda följande DMV-fråga för att se hur långt redo-tråden har halkat efter, genom att mäta skillnaden i avståndet mellan last_redone_lsn och last_received_lsn.

select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,   
   last_redone_lsn, last_redone_time  
from sys.dm_hadr_database_replica_states

Om redo-tråden verkligen halkar efter behöver du undersöka grundorsaken till prestandaförsämringen på sekundärkopian. Om det uppstår en I/O-konflikt med rapporteringsarbetsbelastningen kan du använda Resource Governor för att styra CPU-cykler som rapporteringsarbetsbelastningen använder för att indirekt styra de I/O-cykler som tas, till viss del. Till exempel, om din rapporteringsarbetsbelastning förbrukar 10 procent av CPU:n men arbetsbelastningen är I/O-bunden, kan du använda Resource Governor för att begränsa CPU-resursanvändningen till 5 procent för att strypa läsbelastningen, vilket minimerar påverkan på I/O.

Relaterat innehåll

  • Uppdaterades senast