Bild: traffic_analyzer/Getty ImagesDatabaser är underbara saker, tills de går fel. Sedan väntar du på en återhämtning för att varva ner långa transaktioner och spela upp loggfiler. Ju mer komplexa transaktionerna är, desto längre tid kan återhämtningen ta, vilket gör att du litar på alternativa lösningar för att hålla ditt företag igång. Långsam återhämtning är dyrt, kostar tid och pengar.
Så hur kan vi få tillbaka våra databaser snabbt, med minimala avbrott i affärsprocesser? Ibland kräver det att man går tillbaka till grundforskningen, eller i det här fallet till ett Microsoft Research-dokument från 2019 med titeln “Constant Time Recovery in Azure SQL Database”. Tidningen är fascinerande och lovar ett sätt att återställa databaser i konstant tid med mindre loggfiler. Även om det tydligt är inriktat på molntjänster, där att hålla återställningslagring till ett minimum har ett tydligt ekonomiskt värde, är det en teknik som kan fungera var som helst. Fördelarna verkar verkligen klara, med de flesta återhämtningar som tar mindre än tre minuter istället för timmar.
Det gamla sättet: VÄDUR
Vad är hett på TechRepublic
De flesta databaser, inklusive SQL Server och Azure SQL, är beroende av ARIES-protokollet. Algoritmen för återhämtning och isolering Utnyttja semantik är ett grundläggande verktyg för moderna databaser, som använder skriv-förut-loggning för att tillhandahålla ett sätt att återställa databastillstånd. ARIES använder tre typer av logg, endast ångra, endast gör om och ångra-gör om. Dessa registrerar varje uppdatering, med typen av logg som avgör vilken typ av återställning som kan göras, i syfte att antingen återställa till ett före- eller eftertillstånd för varje uppdateringsoperation i din databas, och hantera ändringar i dina poster och tabeller.
Både SQL Server och Azure SQL använder transaktionsloggen för att spela om operationer från det senast kända goda tillståndet, analysera loggen för att bestämma tillståndet för alla registrerade transaktioner, göra om genomförda transaktioner i ordning från äldsta till nyaste, samtidigt som oengagerade transaktioner ångras i omvänd ordning, från nyaste till äldsta. När denna process är klar är din databas online igen och redo att användas. Det finns mycket för SQL Server att hantera i en ARIES-återställning, eftersom en fullständig återställning kan kräva två eller tre passeringar genom loggarna, speciellt när du har att göra med långa transaktioner som kräver flera uppdateringar.
SE: Resurs- och dataåterställningspolicy (TechRepublic Premium)
Det finns sätt att förbättra prestanda här, vanligtvis med att dra fördel av parallella bearbetningstekniker, men de kräver betydande hårdvaruinvesteringar och kräver kraftfulla servrar. Det kan vara bra för lokala databaser där du är beredd att ha den nödvändiga hårdvaran i handen, men det är inte riktigt praktiskt i molnet där databasen inte bara körs på optimerad hårdvara, utan de kan också ofta vara storleksordningar större än på din egen hårdvara. Det finns andra problem kring molnplattformars användning av multi-tenancy, där beräkningsresurser delas på hårdvara som körs med högre belastning. De resulterande begränsningarna för molnoperationer innebär att failover och återställning är mycket mer sannolikt än i lokaler, så det är viktigt att ha en snabbare återställningsprocess.
Och nu till det nya: ADR
Microsofts nya databasåterställningsteknik är avsedd att undvika problemen som kommer med molnåterställning, hålla stilleståndstiden till ett minimum samtidigt som det inte kräver extra resurser, oavsett hur stor arbetsbelastningen är.
Den nya konstanttidsåterställningsalgoritmen blandar ARIES med SQL Servers Multi-version Concurrency Control. Designad för att hantera samtidiga transaktioner, använder MVCC en temporär databas för att lagra olika versioner av rader som datauppdateringar, rangordna ändringar baserat på transaktions-ID och tidsstämplar. Denna butik raderas varje gång databasen startas om eftersom den bara behövs för att upprätthålla isolering mellan samtidiga transaktioner. Gamla rader rullar bort från databasen, vilket håller lagringskraven låga.
Denna butik är grunden för konstant tidsåterställning, som både Azure SQL och SQL Server nu kallar Accelerated Database Recovery (ADR). Istället för att vänta på att transaktionsloggarna ska rulla tillbaka får du nu nästan omedelbar återställning av transaktioner, utan effekter från långvariga transaktioner. Och eftersom det underliggande systemet är baserat på MVCC-butiken, hålls det litet, eller som Microsoft beskriver det, “aggressivt trunkerat.” Denna version av MVCC är en del av användardatabasen och hänvisas till som Persisted Version Store (den ursprungliga MVCC förblir en separat butik och fortsätter att stödja Azure SQLs samtidighetsfunktioner).
Implementera Constant Time Recovery
Även om återställningsprocessen är mycket lik den som används av ARIES, är den mycket snabbare eftersom den inte behöver bearbeta hela transaktionsloggen. Istället används data i den nya PVS för att ge en omedelbar uppspelning av transaktioner mellan den sista kontrollpunkten och den äldsta icke-begärda transaktionen. Detta lämnar bara en kort period av transaktioner att göra om. Samtidigt används en ny loggström i minnet för att spela om operationer utan version, som cachehantering och lås, och samtidigt hålla transaktionsloggen liten. Denna sekundära loggström (sLogen) kopieras till transaktionsloggen vid checkpoints, och håller den liten men säkerställer att dess data finns där om du behöver replikera en hel databas som en del av en affärsåterställningsprocess.
Om du använder Azure SQL Database och Aure SQL Managed Instance använder du redan ADR. Det är också tillgängligt för andra SQL Server-baserade databaser, inklusive SQL Server 2019 och Azure Synapse SQL. Om du använder SQL Server 2019 kanske ADR inte är nödvändigt för alla dina operationer, men det är verkligen värt att överväga om du har långa transaktioner, stora transaktionsloggar eller där databasåterställning har orsakat betydande avbrott tidigare. Det finns vissa fall, som när du använder databasspegling, att det inte stöds.
För att aktivera ADR, använd SQL Server-kommandoraden för att växla ADR på eller av, och för att definiera filgruppen som används för att vara värd för dess PVS-data. Processen kan ta lite tid och påverka normala funktioner eftersom den låser din databas medan den körs, vilket förhindrar att nya sessioner startar tills installationen är klar. När låset släpps kommer din databas att skyddas av ADR.
Det är en enkel förändring som har stor effekt och undviker betydande stilleståndstider i komplexa dataapplikationer. Men som alla enkla ändringar beror den ena raden kod på mycket arbete från Microsofts SQL Server-team och deras motsvarigheter i Microsoft Research. Det här är ett tillfälle där vi enkelt kan se hur forskning blir en produkt och hur den kan ha stor inverkan inte bara på Azure utan i våra egna datacenter.
