Att planera och rulla ut en plan för hög tillgänglighet och katastrofåterställning som uppfyller alla servicenivåavtal är ett icke-trivialt åtagande och kräver en mycket tydlig förståelse av SQL Servers inbyggda styrkor och svagheter. När kraven matchas mot en kombination av funktioner kan några av de kritiska detaljerna försvinna, och i det här inlägget kommer jag att gå igenom några vanliga snedvridningar och dåliga antaganden som kan smyga sig in i en lösning – vilket i slutändan får oss att missa målet. på vår återhämtningspunkt och mål för återhämtningstid. Några av exemplen på förvrängningar eller självbedrägerier som jag beskriver här kan generaliseras över olika egenskaper och några är funktionsspecifika.
"Vi testade vår katastrofåterställningsplan när vi först lanserade vårt projekt och vi vet att det kommer att fungera"
Jag har arbetat med kunder som verkligen fick sin katastrofåterställning "rätt" - en gång. Men när alla kände sig säkra på effektiviteten av lösningen, utfördes inga andra katastrofåterställningsövningar igen. Naturligtvis – under tiden fortsätter datanivån och applikationen att förändras över tiden. Dessa ändringar introducerar nya objekt och processer som är avgörande för applikationen. Och även om allt förblir statiskt efter lanseringen måste du fortfarande ta hänsyn till personalomsättning och varierande kompetens. Kan dagens personal framgångsrikt utföra en katastrofåterställningsövning? Och även den bästa personalen behöver löpande övning.
"Vi kommer inte att förlora några data eftersom vi använder synkron databasspegling"
Låt oss säga att du använder synkron databasspegling mellan två SQL Server-instanser, med varje instans i ett separat datacenter. Antag i det här exemplet att transaktionslatensen är acceptabel trots att detta är en synkron databasspeglingssession med några mil mellan datacentren. Du har inget vittne i mixen eftersom du vill styra databasspegelns failover manuellt.
Låt oss nu säga att ditt datacenter för katastrofåterställning försvinner – men ditt primära datacenter är fortfarande tillgängligt. Din huvuddatabas är frånkopplad från spegeldatabasen, men den accepterar fortfarande anslutningar och dataändringar. Hur är det med kravet på "ingen dataförlust" nu? Om transaktioner körde mot den frånkopplade huvudmannen i ytterligare en timme, vad är din plan om det primära datacentret också går förlorat?
"Vår företagsägare säger att vi kan förlora upp till 12 timmars data"
Det är viktigt att ställa vissa frågor mer än en gång och till mer än en individ i en organisation. Om någon säger till dig att "12 timmars dataförlust är acceptabelt" – fråga dem igen, eller fråga dem vad konsekvensen av den dataförlusten skulle bli. Fråga andra människor också. De kan ge dig ett mycket strängare krav. Jag har märkt att mål för återhämtningspunkter kräver en del förhandlingar och mer än några genomtänkta, medvetna diskussioner.
"Vi använder [databasspegling eller tillgänglighetsgrupper] och därför är vi täckta för vad vi behöver i händelse av en katastrof"
Databasspegling och tillgänglighetsgrupper kan säkert användas för att skydda dig på databasnivå, men hur är det med allt annat? Hur är det med dina inloggningar? SSIS-paket? Jobb? Icke-FULLSTÄNDA återställningsmodelldatabaser? Länkade servrar?
"Vi använder SQL Server-funktionen XYZ, så vi kommer inte att förlora några transaktioner under flygningen"
Nej, tyvärr. Även om vissa funktioner tillåter transparent omdirigering, är detta inte detsamma som att behålla och bevara öppna transaktioner vid tidpunkten för failover. Ingen SQL Server-funktion tillhandahåller denna funktion i dag.
"Teamet som stödjer datanivån för den här applikationen hatar SQL Server-funktionen XYZ, men vi går vidare med det eftersom det var det som rekommenderades till oss av en extern konsult"
Även om det skulle vara trevligt om folk inte utvecklade specifika fördomar kring funktioner i SQL Server, är det ofta inte fallet. Om du försöker tvinga fram lösningar på en personal som inte är ombord med dem, löper du risken för förutbestämt misslyckande. Som en del av HA/DR-övningarna jag har hjälpt till med tidigare är jag alltid intresserad av att höra om människors tidigare erfarenheter av specifika egenskaper. Till exempel utnyttjar vissa företag hundratals Failover Cluster Instances mycket väl – medan andra undviker dem på grund av dåliga erfarenheter från tidigare versioner. När du planerar en lösning kan du inte ignorera historik eller anlag för personalen som i slutändan kommer att ansvara för att implementera och stödja den rekommenderade lösningen.
"Som DBA bestämmer jag vilken HA/DR-teknik som ska användas för datanivån, så vi kommer att använda tillgänglighetsgrupper framöver"
En databasadministratör kan eventuellt ställa in databasspegling med liten eller ingen inblandning i andra team. Nu med tillgänglighetsgrupper, även om en databasadministratör skulle kunna göra allt på egen hand, kan de vara oklokt att göra det. När allt kommer omkring – om du distribuerar tillgänglighetsgrupper för katastrofåterställningsändamål, vill du att alla som är inblandade i en katastrofåterställningsoperation ska vara medvetna om din lösning och de krav som krävs för att framgångsrikt komma tillbaka online och återställa data. Med tillgänglighetsgrupper måste du tänka på Windows Server Failover Cluster, kvorumkonfigurationer, nodröster, tillgänglighetsgruppavlyssnaren och mer. Om du behöver andra personer för att underlätta en lösning, se till att de är involverade i den första rekommendationen.
"Vi använder tillgänglighetsgrupper så att vi kan ha skrivskyddad tillgänglighet i händelse av ett avbrott i vår läs-skriv-replika"
Detta är bara ett exempel på ett "tänk om"-scenario. Med vilken funktionalitet som helst, vill du föreställa dig de olika sätten som fel kan uppstå – och se till att testa det för att säkerställa att dina krav fortfarande uppfylls. Till exempel – om du tror att din SQL Server 2012-tillgänglighetsgrupp asynkrona skrivskyddade replikor kommer att vara tillgängliga när läs-skriv-repliken inte är tillgänglig, kommer du att bli obehagligt förvånad över att se
"Vi testade SQL Server-funktionen XYZ och failover gick snabbt, så vi har fastställt att vi enkelt kan nå våra mål för återställningstid"
Låt oss säga att du bestämmer dig för att använda databasspegling för hög tillgänglighet på användardatabasnivå. Du vill ha snabb failover (mätt i sekunder), och du ser verkligen snabb failover under testning. Men var det ett realistiskt test? Utövade du en betydande arbetsbörda? I exemplet med databasspegling kan den längsta delen av din failover-operation vara för redo-operationerna. Om du inte kör realistiska arbetsbelastningar kan du inte riktigt säga att din failover faktiskt kommer att vara "snabb".
"Om vi råkar ut för en katastrof och behöver rädda och stämma av data, kommer vi att ta reda på det när det är dags"
Det här är en tuff sådan. Låt oss säga att du har en katastrof och behöver göra ditt sekundära datacenter i drift. Du bestämmer dig för att tvinga fram service för de mest kritiska databaserna i det sekundära datacentret och du har nu en splittring i linjen av datamodifieringar (några oavstämda rader i det primära datacentret, och nu nya modifieringar i det sekundära datacentret). Så småningom läggs ditt primära datacenter online – men nu har du data som måste räddas och stämmas av innan du kan återupprätta den övergripande HA/DR-lösningen. Vad gör du? Vad kan du göra? Den här diskussionen är sällan lätt att ha och kan bero på flera faktorer som mjukvarupaketen du har köpt, datanivåns komplexitet och datakonvergensverktygen till ditt förfogande. Faktum är att diskussionen vanligtvis är så svår att folk inte har det alls. Men om data är tillräckligt kritiska för att du ska ha satt upp ett sekundärt datacenter, bör en viktig del av diskussionen inkludera hur man bäst kan rädda data och även stämma av dem efter att en katastrof har inträffat.
Sammanfattning
Den här artikeln inkluderade bara några exempel på hur vi kan lura oss själva att tro att en lösning helt uppfyller deras krav. Även om det är mänsklig natur att göra detta – när det kommer till dataförlust och affärskontinuitet, kommer våra jobb att bero på att vi är mer aggressiva när det gäller att testa våra egna övertygelser och antaganden.