Databassystem har ett ansvar att lagra och säkerställa konsekvent tillgänglighet av relevant data när det behövs när som helst i drift. De flesta företag misslyckas med att fortsätta sin verksamhet efter fall av dataförlust till följd av databasfel, säkerhetsbrygga, mänskliga fel eller katastrofala fel som helt kan förstöra driftnoderna i produktionen. Att hålla databaser i samma datacenter löper en stor risk att förlora all data i händelse av dessa övergrepp.
replikering och säkerhetskopiering är de vanligaste sätten att säkerställa hög tillgänglighet för data. Valet mellan de två beror på hur ofta data ändras. Säkerhetskopiering är bäst att föredra där data inte ändras oftare och ingen förväntar sig att ha så många säkerhetskopior. Å andra sidan är replikering att föredra för att ofta ändra data förutom några andra fördelar som är associerade som att servera data på en specifik plats genom att minska fördröjningen av förfrågningar. Men både replikering och säkerhetskopiering kan användas för maximal dataintegritet och konsistens under återställning i alla fall av fel.
Säkerhetskopiering av databas ger fler fördelar förutom att ge en återställningspunkt för att tillhandahålla grunderna för att skapa nya miljöer för utveckling, öppen åtkomst och iscensättning utan att behöva angripa produktionen. Utvecklingsteamet kan snabbt och enkelt testa nyintegrerade funktioner och påskynda utvecklingen. Säkerhetskopior kan också användas till kontrollpunkten för kodfel där de resulterande data inte är konsekventa.
Överväganden för att säkerhetskopiera MongoDB
Säkerhetskopieringar skapas vid vissa tillfällen för att återspegla (fungerar som en ögonblicksbild av databasen) vilken data databasen är värd för vid det givna ögonblicket. Om databasen misslyckas vid en given punkt kan vi använda den sista säkerhetskopian för att rulla tillbaka DB till en punkt innan den misslyckades. Man måste dock ta hänsyn till vissa faktorer innan man gör en återhämtning och de inkluderar:
- Återställningspunktsmål
- Återhämtningstidsmål
- Isolering av databas och ögonblicksbilder
- Komplikationer med delning
- Återställningsprocess
- Prestandafaktorer och tillgänglig lagring
- Flexibilitet
- Komplexiteten i implementeringen
Återställningspunktsmål
Detta görs för att avgöra hur mycket data du är redo att förlora under säkerhetskopieringen och återställningsprocessen. Till exempel, om vi har användardata och klickströmsdata, kommer användardata att prioriteras framför klickströmsanalysen eftersom den senare kan återskapas genom att övervaka operationer i din applikation efter återställning. En kontinuerlig säkerhetskopiering bör föredras för kritiska data såsom bankinformation, produktionsindustridata och kommunikationssysteminformation och bör utföras med korta intervaller. Om data inte ändras ofta kan det bli billigare att förlora mycket av det om du gör en återställd ögonblicksbild av till exempel 6 månader eller 1 år tidigare.
Återställningstidsmål
Detta är för att analysera och bestämma hur snabbt återställningen kan göras. Under återställning kommer dina applikationer att drabbas av en viss driftstopp som också är direkt proportionell mot mängden data som behöver återställas. Om du återställer en stor uppsättning data kommer det att ta längre tid.
Databas- och ögonblicksbildsisolering
Isolering är ett mått på hur nära backup-ögonblicksbilder är från de primära databasservrarna i termer av logisk konfiguration och fysiskt. Om de råkar vara tillräckligt nära, minskar återställningstiden på bekostnad av ökad sannolikhet att förstöras samtidigt som databasen förstörs. Det är inte tillrådligt att vara värd för säkerhetskopior och produktionsmiljön i samma system för att undvika att eventuella störningar på servrarna också minskar i säkerhetskopiorna.
Komplikationer med Sharding
För ett distribuerat databassystem genom sharding presenteras viss säkerhetskopieringskomplexitet och skrivaktiviteter kan behöva pausas över hela systemet. Olika skärvor avslutar olika typer av säkerhetskopior vid olika tidpunkter. Överväger logiska säkerhetskopior och ögonblicksbilder,
Logiska säkerhetskopior
- Skärvor har olika storlekar och slutar därför vid olika tidpunkter
- MongoDB-basdumpar ignorerar --oplog och kommer därför inte att vara konsekventa vid varje skärva.
- Balansaren kan vara avstängd medan den ska vara på bara för att vissa skärvor kanske inte har avslutat restaureringsprocessen
Säkerhetskopiering av ögonblicksbilder
- Fungerar bra för en enstaka replik från version 3.2 och senare. Du bör därför överväga att uppdatera din MongoDB-version.
Återställningsprocess
Vissa personer gör säkerhetskopior utan att testa om de kommer att fungera i händelse av återställning. En säkerhetskopia är i huvudsak att tillhandahålla en återställningskapacitet, annars blir den värdelös. Du bör alltid försöka köra säkerhetskopiorna på olika testservrar för att se om de fungerar.
Prestandafaktorer och tillgänglig lagring
Säkerhetskopieringar tenderar också att ta många storlekar eftersom data från själva databasen och måste komprimeras tillräckligt för att inte ta upp mycket onödigt utrymme som kan minska systemets totala lagringsresurser. De kan arkiveras i zip-filer och därmed minska deras totala storlek. Dessutom kan man som tidigare nämnt arkivera säkerhetskopiorna i olika datacenter från själva databasen.
Säkerhetskopieringar kan avgöra olika prestanda för databasen eftersom vissa kan försämra den. I så fall kommer kontinuerliga säkerhetskopieringar att ge ett visst bakslag och bör därför konverteras till schemalagda säkerhetskopieringar för att undvika uttömning av underhållsfönster. I de flesta fall distribueras sekundära servrar för att stödja säkerhetskopiering. I det här fallet:
- Enstaka noder kan inte säkerhetskopieras konsekvent eftersom MongoDB använder read-uncommitted utan en oplog när man använder kommandot mongodump och i så fall kommer säkerhetskopieringar inte att vara säkra.
- Använd sekundära noder för säkerhetskopiering eftersom själva processen tar tid beroende på mängden data som är involverad och de anslutna applikationerna kommer att medföra lite driftstopp. Om du använder den primära som också måste uppdatera Oplogs, kan du förlora en del data under driftstoppet
- Återställningsprocessen tar mycket tid men de tilldelade lagringsresurserna är små.
Flexibilitet
Många ibland kanske du inte vill ha en del av data under säkerhetskopieringen, som för exemplet med Recovery Point Objective, kan man vilja att återställningen görs och filtrera bort användarklicksdata. För att göra det behöver du en partiell säkerhetskopieringsstrategi som ger flexibiliteten att filtrera bort data som du inte är intresserad av, vilket minskar återställningstiden och resurserna som skulle ha gått till spillo. Inkrementell säkerhetskopiering kan också vara användbar så att endast datadelar som har ändrats kommer att säkerhetskopieras från den senaste ögonblicksbilden istället för att ta hela säkerhetskopior för varje ögonblicksbild.
Komplexiteten i implementeringen
Din säkerhetskopieringsstrategi bör vara lätt att ställa in och underhålla med tiden. Du kan också schemalägga dina säkerhetskopior så att du inte behöver göra dem manuellt när du vill.
Slutsats
Databassystem garanterar "liv efter döden" om det bara finns ett väletablerat backup-system på plats. Databasen kan förstöras av katastrofala faktorer, mänskliga fel eller säkerhetsattacker som kan leda till förlust eller korruption av data. Innan man gör en säkerhetskopia måste man överväga typen av data när det gäller storlek och betydelse. Det är alltid inte tillrådligt att förvara dina säkerhetskopior i samma datacenter som din databas för att minska sannolikheten för att säkerhetskopiorna förstörs samtidigt. Säkerhetskopieringar kan förändra databasens prestanda, därför bör man vara försiktig med strategin som ska användas och när säkerhetskopieringen ska utföras. Gör inte dina säkerhetskopior på den primära noden eftersom det kan resultera i systemavbrott under säkerhetskopieringen och följaktligen förlora viktig data.