Produktionsafbrydelser er næsten garanteret at forekomme på et tidspunkt. At acceptere denne kendsgerning og analysere tidslinjen og fejlscenariet for din databaseudfald kan hjælpe med bedre at forberede, diagnosticere og genoprette den næste. For at afbøde virkningen af nedetid har organisationer brug for en passende katastrofegenopretningsplan (DR). DR-planlægning er en kritisk opgave for mange SysOps/DevOps, men selvom det er forudset; ofte findes den ikke.
I dette blogindlæg vil vi analysere forskellige backup- og fejlscenarier i MongoDB-databasesystemer. Vi vil også lede dig gennem gendannelses- og failover-procedurer for hvert respektive scenarie. Disse use cases vil variere fra gendannelse af en enkelt node, gendannelse af en node i et eksisterende replicaSet og seeding af en ny node i et replicaSet. Forhåbentlig vil dette give dig en god forståelse af de risici, du kan stå over for, og hvad du skal overveje, når du designer din infrastruktur.
Før vi begynder at diskutere mulige fejlscenarier, lad os tage et kig på, hvordan MongoDB gemmer data, og hvilke typer sikkerhedskopiering der er tilgængelige.
Hvordan MongoDB gemmer data
MongoDB er en dokumentorienteret database. I stedet for at gemme dine data i tabeller lavet af individuelle rækker (som en relationel database gør), gemmer den data i samlinger lavet af individuelle dokumenter. I MongoDB er et dokument en stor JSON-blob uden noget bestemt format eller skema. Derudover kan data spredes på tværs af forskellige klynge noder med deling eller replikeres til slaveservere med replicaSet.
MongoDB giver som standard meget hurtige skrivninger og opdateringer. Afvejningen er, at du ofte ikke får eksplicit besked om fejl. Som standard laver de fleste drivere asynkrone, usikre skrivninger. Det betyder, at driveren ikke returnerer en fejl direkte, svarende til INSERT DELAYED med MySQL. Hvis du vil vide, om noget lykkedes, skal du manuelt tjekke for fejl ved hjælp af getLastError.
For optimal ydeevne foretrækkes det at bruge SSD frem for HDD til opbevaring. Det er nødvendigt at tage sig af, om dit lager er lokalt eller fjernt, og træffe foranstaltninger i overensstemmelse hermed. Det er bedre at bruge RAID til beskyttelse af hardwarefejl og gendannelsesordninger, men stol ikke helt på det, da det ikke tilbyder beskyttelse mod uønskede fejl. Den rigtige hardware er byggestenen til din applikation for at optimere ydeevnen og undgå en større debacle.
Datakorruption på diskniveau eller manglende datafiler kan forhindre mongod-forekomster i at starte, og journalfiler kan være utilstrækkelige til at gendanne automatisk.
Hvis du kører med journalføring aktiveret, er der næsten aldrig behov for at køre reparation, da serveren kan bruge journalfilerne til automatisk at gendanne datafilerne til en ren tilstand. Du skal dog muligvis stadig køre reparation i tilfælde, hvor du har brug for at gendanne datakorruption på diskniveau.
Hvis journalføring ikke er aktiveret, kan din eneste mulighed være at køre reparationskommando. mongod --repair bør kun bruges, hvis du ikke har andre muligheder, da operationen fjerner (og ikke gemmer) eventuelle korrupte data under reparationsprocessen. Denne type operation bør altid forudgås med backup.
MongoDB Disaster Recovery Scenario
I en fejlgendannelsesplan er dit Recovery Point Objective (RPO) en nøglegendannelsesparameter, der dikterer, hvor meget data du har råd til at miste. RPO er listet i tid, fra millisekunder til dage og er direkte afhængig af dit backup-system. Den tager hensyn til alderen på dine sikkerhedskopierede data, som du skal gendanne for at kunne genoptage normal drift.
For at estimere RPO skal du stille dig selv et par spørgsmål. Hvornår er mine data sikkerhedskopieret? Hvad er SLA'en forbundet med hentning af dataene? Er det acceptabelt at gendanne en sikkerhedskopi af dataene, eller skal dataene være online og klar til at blive forespurgt på ethvert givet tidspunkt?
Svar på disse spørgsmål vil hjælpe med at drive, hvilken type backup-løsning du har brug for.
MongoDB Backup Solutions
Sikkerhedskopieringsteknikker har varierende indflydelse på den kørende databases ydeevne. Nogle sikkerhedskopieringsløsninger forringer databasens ydeevne nok til, at du muligvis skal planlægge sikkerhedskopier for at undgå spidsbelastnings- eller vedligeholdelsesvinduer. Du kan beslutte at installere nye sekundære servere bare for at understøtte sikkerhedskopiering.
De tre mest almindelige løsninger til backup af din MongoDB-server/-klynge er...
- Mongodump/Mongorestore - logisk backup.
- Mongo Management System (Cloud) - Produktionsdatabaser kan sikkerhedskopieres ved hjælp af MongoDB Ops Manager, eller hvis du bruger MongoDB Atlas-tjenesten, kan du bruge en fuldt administreret backup-løsning.
- Snapshots af databasen (sikkerhedskopi på diskniveau)
Mongodump/Mongorestore
Når du udfører en mongodump, vil alle samlinger i de udpegede databaser blive dumpet som BSON-output. Hvis der ikke er angivet nogen database, vil MongoDB dumpe alle databaser undtagen admin-, test- og lokale databaser, da de er reserveret til intern brug.
Som standard vil mongodump oprette en mappe kaldet dump, med en mappe for hver database, der indeholder en BSON-fil pr. samling i den database. Alternativt kan du bede mongodump om at gemme sikkerhedskopien i en enkelt arkivfil. Arkivparameteren vil sammenkæde outputtet fra alle databaser og samlinger til en enkelt strøm af binære data. Derudover kan gzip-parameteren naturligvis komprimere dette arkiv ved at bruge gzip. I ClusterControl streamer vi alle vores sikkerhedskopier, så vi aktiverer både arkiv- og gzip-parametrene.
I lighed med mysqldump med MySQL, hvis du opretter en sikkerhedskopi i MongoDB, vil den fryse samlingerne, mens indholdet dumpes til backupfilen. Da MongoDB ikke understøtter transaktioner (ændret i 4.2), kan du ikke lave en 100 % fuldstændig konsistent sikkerhedskopiering, medmindre du opretter sikkerhedskopien med oplog-parameteren. Aktivering af dette på sikkerhedskopien inkluderer transaktionerne fra oploggen, der blev udført under sikkerhedskopieringen.
For bedre automatisering og Du kan køre MongoDB fra kommandolinjen eller bruge eksterne værktøjer som ClusterControl. ClusterControl anbefales til backupstyring og backupautomatisering, da det giver mulighed for at skabe avancerede backupstrategier til forskellige open source-databasesystemer.
ClusterControl giver dig mulighed for at uploade din backup til skyen. Det understøtter fuld backup og gendanner krypteringen af mongodump. Hvis du vil se, hvordan det virker, er der en demo på vores hjemmeside.
Gendannelse af MongoDB fra en sikkerhedskopi
Der er grundlæggende to måder, du kan bruge en BSON-formatdump på:
- Kør mongod direkte fra backup-mappen
- Kør mongorestore og gendan sikkerhedskopien
Kør mongod direkte fra en sikkerhedskopi
En forudsætning for at køre mongod direkte fra sikkerhedskopien er, at backupmålet er et standarddump og ikke er gzippet.
MongoDB-dæmonen vil derefter kontrollere integriteten af databiblioteket, tilføje admindatabasen, journaler, samlings- og indekskataloger og nogle andre filer, der er nødvendige for at køre MongoDB. Hvis du før kørte WiredTiger som lagringsmotor, vil den nu køre de eksisterende samlinger som MMAP. For simple datadumps eller integritetstjek fungerer dette fint.
Kører mongorestore
En bedre måde at gendanne på ville naturligvis være ved at gendanne noden ved hjælp af en mongorestore.
mongorestore dump/Dette vil gendanne sikkerhedskopien til standardserverindstillingerne (localhost, port 27017) og overskrive alle databaser i sikkerhedskopien, der ligger på denne server. Nu er der tonsvis af parametre til at manipulere gendannelsesprocessen, og vi vil dække nogle af de vigtige.
I ClusterControl gøres dette i muligheden for gendannelse af sikkerhedskopiering. Du kan vælge maskinen, hvornår sikkerhedskopien skal gendannes, og behandle med tage sig af resten. Dette inkluderer krypteret sikkerhedskopiering, hvor du normalt også skulle dekryptere din sikkerhedskopi.
Objektvalidering
Da sikkerhedskopien indeholder BSON-data, forventer du, at indholdet af sikkerhedskopien er korrekt. Det kunne dog have været tilfældet, at det dokument, der blev dumpet, var forkert udformet til at begynde med. Mongodump kontrollerer ikke integriteten af de data, den dumper.
For at løse denne brug -- objcheck som tvinger mongorestore til at validere alle anmodninger fra klienter ved modtagelse for at sikre, at klienter aldrig indsætter ugyldige dokumenter i databasen. Det kan have en lille indvirkning på ydeevnen.
Oplog Replay
Oplog til din sikkerhedskopi vil gøre dig i stand til at udføre en konsekvent sikkerhedskopiering og foretage en punkt-in-tids-gendannelse. Aktiver oplogReplay-parameteren for at anvende oplog under gendannelsesprocessen. For at kontrollere, hvor langt oploggen skal afspilles igen, kan du definere et tidsstempel i parameteren oplogLimit. Kun transaktioner indtil tidsstemplet vil derefter blive anvendt.
Gendannelse af et komplet replikasæt fra en sikkerhedskopi
Gendannelse af et replicaSet er ikke meget anderledes end at gendanne en enkelt node. Enten skal du konfigurere replicaSet først og gendanne direkte i replicaSet. Eller du gendanner først en enkelt node og derefter bruger denne gendannede node til at bygge et replikasæt.
Gendan først node, og opret derefter replicaSet
Nu vil den anden og tredje node synkronisere deres data fra den første node. Efter at synkroniseringen er afsluttet, er vores replicaSet blevet gendannet.
Opret et ReplicaSet først, og gendan derefter
I modsætning til den tidligere proces kan du først oprette replikasættet. Konfigurer først alle tre værter med replicaSet aktiveret, start alle tre dæmoner og start replicaSet på den første node:
Nu hvor vi har oprettet replikasættet, kan vi gendanne vores backup direkte i det:
Efter vores mening er det meget mere elegant at gendanne et replicaSet på denne måde. Det er tættere på den måde, du normalt ville sætte et nyt replikaSet op fra bunden og derefter fylde det med (produktions)data.
Seeding af en ny node i et replikasæt
Når du skalerer en klynge ud ved at tilføje en ny node i MongoDB, skal den indledende synkronisering af datasættet ske. Med MySQL-replikering og Galera er vi så vant til at bruge en backup til at se den indledende synkronisering. Med MongoDB er dette muligt, men kun ved at lave en binær kopi af databiblioteket. Hvis du ikke har midlerne til at lave et snapshot af filsystemet, bliver du nødt til at stå over for nedetid på en af de eksisterende noder. Processen med nedetid er beskrevet nedenfor.
Seeding med en sikkerhedskopi
Så hvad ville der ske, hvis du gendanner den nye node fra en mongodump-sikkerhedskopi i stedet for og derefter får den til at slutte sig til et replicaSet? Gendannelse fra en sikkerhedskopi skulle i teorien give det samme datasæt. Da denne nye node er blevet gendannet fra en sikkerhedskopi, vil den mangle replicaSetId, og MongoDB vil bemærke det. Da MongoDB ikke ser denne node som en del af replicaSet, vil kommandoen rs.add() altid udløse MongoDB initial synkronisering. Den indledende synkronisering vil altid udløse sletning af eksisterende data på MongoDB-knuden.
replicaSetId'et genereres, når et replicaSet startes, og kan desværre ikke indstilles manuelt. Det er en skam, da gendannelse fra en sikkerhedskopi (inklusive genafspilning af oploggen) teoretisk set ville give os et 100% identisk datasæt. Det ville være rart, hvis den indledende synkronisering var valgfri i MongoDB for at tilfredsstille denne use case.