Produktionsavbrott är nästan garanterat att inträffa någon gång. Att acceptera detta faktum och analysera tidslinjen och felscenariot för ditt databasavbrott kan hjälpa dig att bättre förbereda, diagnostisera och återhämta dig från nästa. För att mildra effekterna av driftstopp behöver organisationer en lämplig katastrofåterställningsplan (DR). DR-planering är en kritisk uppgift för många SysOps/DevOps, men även om det är förutsett; ofta finns det inte.
I det här blogginlägget kommer vi att analysera olika backup- och felscenarier i MongoDB-databassystem. Vi kommer också att leda dig genom återställnings- och failover-procedurer för varje respektive scenario. Dessa användningsfall kommer att variera från att återställa en enstaka nod, återställa en nod i en befintlig replicaSet och att se en ny nod i en replicaSet. Förhoppningsvis kommer detta att ge dig en god förståelse för de risker du kan ställas inför och vad du bör tänka på när du utformar din infrastruktur.
Innan vi börjar diskutera möjliga felscenarier, låt oss ta en titt på hur MongoDB lagrar data och vilka typer av säkerhetskopiering som är tillgängliga.
Hur MongoDB lagrar data
MongoDB är en dokumentorienterad databas. Istället för att lagra dina data i tabeller gjorda av individuella rader (som en relationsdatabas gör), lagrar den data i samlingar gjorda av enskilda dokument. I MongoDB är ett dokument en stor JSON-klump utan något speciellt format eller schema. Dessutom kan data spridas över olika klusternoder med delning eller replikeras till slavservrar med replicaSet.
MongoDB tillåter mycket snabba skrivningar och uppdateringar som standard. Avvägningen är att du ofta inte uttryckligen meddelas om misslyckanden. Som standard gör de flesta förare asynkrona, osäkra skrivningar. Detta innebär att drivrutinen inte returnerar ett fel direkt, liknande INSERT DELAYED med MySQL. Om du vill veta om något har lyckats måste du manuellt söka efter fel med getLastError.
För optimal prestanda är det att föredra att använda SSD istället för hårddisk för lagring. Det är nödvändigt att ta hand om din lagring är lokal eller fjärransluten och vidta åtgärder därefter. Det är bättre att använda RAID för att skydda hårdvarufel och återställningsscheman, men lita inte helt på det eftersom det inte erbjuder skydd mot negativa fel. Rätt hårdvara är byggstenen för din applikation för att optimera prestanda och undvika ett stort problem.
Datakorruption på disknivå eller saknade datafiler kan hindra mongod-instanser från att starta, och journalfiler kan vara otillräckliga för att återställas automatiskt.
Om du kör med journalföring aktiverat finns det nästan aldrig något behov av att köra reparation eftersom servern kan använda journalfilerna för att automatiskt återställa datafilerna till ett rent tillstånd. Du kan dock fortfarande behöva köra reparation i fall där du behöver återställa från datakorruption på disknivå.
Om journalföring inte är aktiverat kan ditt enda alternativ vara att köra reparationskommando. mongod --repair bör endast användas om du inte har några andra alternativ eftersom operationen tar bort (och inte sparar) eventuella korrupta data under reparationsprocessen. Denna typ av operation bör alltid föregås av säkerhetskopiering.
MongoDB-katastrofåterställningsscenario
I en felåterställningsplan är ditt återställningspunktsmål (RPO) en viktig återställningsparameter som bestämmer hur mycket data du har råd att förlora. RPO listas i tid, från millisekunder till dagar och är direkt beroende av ditt backupsystem. Den tar hänsyn till åldern på dina säkerhetskopierade data som du måste återställa för att kunna återuppta normal drift.
För att uppskatta RPO måste du ställa dig själv några frågor. När säkerhetskopieras min data? Vad är SLA förknippat med hämtning av data? Är det acceptabelt att återställa en säkerhetskopia av data eller måste data vara online och redo att frågas när som helst?
Svar på dessa frågor hjälper dig att driva vilken typ av säkerhetskopieringslösning du behöver.
MongoDB Backup Solutions
Säkerhetskopieringstekniker har olika inverkan på prestandan för den pågående databasen. Vissa säkerhetskopieringslösningar försämrar databasprestanda tillräckligt för att du kan behöva schemalägga säkerhetskopieringar för att undvika toppanvändning eller underhållsfönster. Du kan välja att distribuera nya sekundära servrar bara för att stödja säkerhetskopior.
De tre vanligaste lösningarna för att säkerhetskopiera din MongoDB-server/kluster är...
- Mongodump/Mongorestore - logisk säkerhetskopiering.
- Mongo Management System (moln) - Produktionsdatabaser kan säkerhetskopieras med MongoDB Ops Manager eller om du använder MongoDB Atlas-tjänsten kan du använda en fullständigt hanterad backuplösning.
- Snapshots av databas (säkerhetskopiering på disknivå)
Mongodump/Mongorestore
När man utför en mongodump, kommer alla samlingar inom de angivna databaserna att dumpas som BSON-utdata. Om ingen databas anges kommer MongoDB att dumpa alla databaser utom admin-, test- och lokala databaser eftersom de är reserverade för internt bruk.
Som standard kommer mongodump att skapa en katalog som heter dump, med en katalog för varje databas som innehåller en BSON-fil per samling i den databasen. Alternativt kan du be mongodump att lagra säkerhetskopian i en enda arkivfil. Arkivparametern kommer att sammanfoga utdata från alla databaser och samlingar till en enda ström av binär data. Dessutom kan gzip-parametern naturligtvis komprimera detta arkiv med hjälp av gzip. I ClusterControl streamar vi alla våra säkerhetskopior, så vi aktiverar både arkiv- och gzip-parametrarna.
I likhet med mysqldump med MySQL, om du skapar en säkerhetskopia i MongoDB kommer den att frysa samlingarna samtidigt som innehållet dumpas till säkerhetskopian. Eftersom MongoDB inte stöder transaktioner (ändrat i 4.2) kan du inte göra en 100 % helt konsekvent säkerhetskopia om du inte skapar säkerhetskopian med oplog-parametern. Att aktivera detta på säkerhetskopian inkluderar transaktionerna från oploggen som kördes när säkerhetskopieringen gjordes.
För bättre automatisering och Du kan köra MongoDB från kommandoraden eller använda externa verktyg som ClusterControl. ClusterControl rekommenderas för säkerhetskopieringshantering och automatisering av säkerhetskopiering, eftersom det gör det möjligt att skapa avancerade säkerhetskopieringsstrategier för olika databassystem med öppen källkod.
ClusterControl låter dig ladda upp din säkerhetskopia till molnet. Den stöder fullständig säkerhetskopiering och återställer krypteringen av mongodump. Om du vill se hur det fungerar finns en demo på vår hemsida.
Återställa MongoDB från en säkerhetskopia
Det finns i princip två sätt du kan använda en BSON-formatdump:
- Kör mongod direkt från backupkatalogen
- Kör mongorestore och återställ säkerhetskopian
Kör mongod direkt från en säkerhetskopia
En förutsättning för att köra mongod direkt från säkerhetskopian är att backupmålet är en standarddump och inte är gzippad.
MongoDB-demonen kommer sedan att kontrollera datakatalogens integritet, lägga till admindatabasen, journaler, samlings- och indexkataloger och några andra filer som behövs för att köra MongoDB. Om du tidigare körde WiredTiger som lagringsmotor kommer den nu att köra de befintliga samlingarna som MMAP. För enkla datadumpar eller integritetskontroller fungerar detta bra.
Kör mongorestore
Ett bättre sätt att återställa skulle uppenbarligen vara genom att återställa noden med en mongorestore.
mongorestore dump/Detta kommer att återställa säkerhetskopian till standardserverinställningarna (localhost, port 27017) och skriva över alla databaser i säkerhetskopian som finns på denna server. Nu finns det massor av parametrar för att manipulera återställningsprocessen, och vi kommer att täcka några av de viktiga.
I ClusterControl görs detta i alternativet för återställning av backup. Du kan välja maskinen när säkerhetskopian ska återställas och bearbeta med ta hand om resten. Detta inkluderar krypterad säkerhetskopia där du normalt också skulle behöva dekryptera din säkerhetskopia.
Objektvalidering
Eftersom säkerhetskopian innehåller BSON-data kan du förvänta dig att innehållet i säkerhetskopian är korrekt. Det kunde dock ha varit så att handlingen som dumpades var missbildad till att börja med. Mongodump kontrollerar inte integriteten hos data som den dumpar.
För att ta itu med den användningen -- objcheck vilket tvingar mongorestore att validera alla förfrågningar från klienter vid mottagandet för att säkerställa att klienter aldrig infogar ogiltiga dokument i databasen. Det kan ha en liten inverkan på prestandan.
Oplog Replay
Oplog till din säkerhetskopia gör det möjligt för dig att utföra en konsekvent säkerhetskopiering och göra en punkt-in-time-återställning. Aktivera oplogReplay-parametern för att tillämpa oploggen under återställningsprocessen. För att styra hur långt du ska spela om oploggen kan du definiera en tidsstämpel i parametern oplogLimit. Endast transaktioner fram till tidsstämpeln kommer då att tillämpas.
Återställa en fullständig replikuppsättning från en säkerhetskopia
Att återställa en replicaSet är inte mycket annorlunda än att återställa en enskild nod. Antingen måste du ställa in replicaSet först och återställa direkt till replicaSet. Eller så återställer du först en enda nod och använder sedan denna återställda nod för att bygga en replikuppsättning.
Återställ noden först och skapa sedan replicaSet
Nu kommer den andra och tredje noden att synkronisera sina data från den första noden. Efter att synkroniseringen är klar har vår replicaSet återställts.
Skapa ett ReplicaSet först och återställ sedan
Till skillnad från föregående process kan du skapa replicaSet först. Konfigurera först alla tre värdarna med replicaSet aktiverat, starta alla tre demoner och initiera replicaSet på den första noden:
Nu när vi har skapat replicaSet kan vi direkt återställa vår säkerhetskopia till den:
Vi tycker att det är mycket mer elegant att återställa en replicaSet på detta sätt. Det är närmare det sätt som du normalt skulle sätta upp ett nytt replikSet från början och sedan fylla det med (produktions)data.
Seedning av en ny nod i en replikuppsättning
När du skalar ut ett kluster genom att lägga till en ny nod i MongoDB måste den initiala synkroniseringen av datamängden ske. Med MySQL-replikering och Galera är vi så vana vid att använda en säkerhetskopia för att starta synkroniseringen. Med MongoDB är detta möjligt, men bara genom att göra en binär kopia av datakatalogen. Om du inte har möjlighet att göra en ögonblicksbild av filsystemet måste du möta driftstopp på en av de befintliga noderna. Processen, med driftstopp, beskrivs nedan.
Seedning med en säkerhetskopia
Så vad skulle hända om du återställer den nya noden från en mongodump-säkerhetskopia istället och sedan låter den gå med i ett replicaSet? Återställning från en säkerhetskopia borde i teorin ge samma datauppsättning. Eftersom denna nya nod har återställts från en säkerhetskopia kommer den att sakna replicaSetId och MongoDB kommer att märka det. Eftersom MongoDB inte ser denna nod som en del av replicaSet, kommer kommandot rs.add() alltid att utlösa MongoDB initiala synkronisering. Den initiala synkroniseringen kommer alltid att utlösa radering av befintliga data på MongoDB-noden.
ReplicaSetId genereras när ett replicaSet initieras och kan tyvärr inte ställas in manuellt. Det är synd eftersom att återställa från en säkerhetskopia (inklusive att spela om oploggen) teoretiskt sett skulle ge oss en 100% identisk datauppsättning. Det skulle vara trevligt om den initiala synkroniseringen var valfri i MongoDB för att tillfredsställa detta användningsfall.