Databasesystemer har et ansvar for at gemme og sikre ensartet tilgængelighed af relevante data, når det er nødvendigt til enhver tid i drift. De fleste virksomheder formår ikke at fortsætte forretningen efter tilfælde af datatab som følge af en databasefejl, sikkerhedsbro, menneskelige fejl eller katastrofale fejl, der fuldstændigt kan ødelægge driftsknuderne i produktionen. At opbevare databaser i det samme datacenter giver en høj risiko for at miste alle data i tilfælde af disse forargelser.
replikering og sikkerhedskopiering er de almindeligt anvendte måder at sikre høj tilgængelighed af data på. Valget mellem de to afhænger af, hvor ofte dataene ændres. Sikkerhedskopiering er bedst at foretrække, hvor data ikke ændres hyppigere og ingen forventning om at have så mange backup-filer. På den anden ende foretrækkes replikering til hyppigt skiftende data ud over nogle andre fordele, der er forbundet, såsom at servere data på et bestemt sted ved at reducere forsinkelsen af anmodninger. Men både replikering og backup kan bruges til maksimal dataintegritet og konsistens under gendannelse i ethvert tilfælde af fejl.
Databasesikkerhedskopiering giver flere fordele udover at give et gendannelsespunkt til at give det grundlæggende til at skabe nye miljøer til udvikling, åben adgang og iscenesættelse uden at temperere med produktionen. Udviklingsteamet kan hurtigt og nemt teste nye integrerede funktioner og accelerere deres udvikling. Sikkerhedskopier kan også bruges til kontrolpunktet for kodefejl, hvor de resulterende data ikke er konsistente.
Overvejelser ved sikkerhedskopiering af MongoDB
Sikkerhedskopier oprettes på bestemte punkter for at afspejle (fungerer som et øjebliksbillede af databasen), hvilke data databasen hoster på det givne tidspunkt. Hvis databasen fejler på et givet tidspunkt, kan vi bruge den sidste backup-fil til at rulle DB'en tilbage til et punkt, før den mislykkedes. Man skal dog tage nogle faktorer i betragtning, før man foretager en genopretning, og de omfatter:
- Recovery Point Mål
- Recovery Time Objective
- Isolering af database og snapshot
- Komplikationer med Sharding
- Gendannelsesproces
- Ydeevnefaktorer og tilgængelig lagerplads
- Fleksibilitet
- Kompleksiteten af implementeringen
Recovery Point Objective
Dette udføres for at bestemme, hvor meget data du er klar til at miste under backup- og gendannelsesprocessen. For eksempel, hvis vi har brugerdata og klikstrømsdata, vil brugerdata blive prioriteret frem for klikstrømsanalysen, da sidstnævnte kan genskabes ved at overvåge operationer i din applikation efter gendannelse. En kontinuerlig sikkerhedskopiering bør foretrækkes for kritiske data såsom bankoplysninger, produktionsindustridata og kommunikationssysteminformation og bør udføres med tætte intervaller. Hvis dataene ikke ændres ofte, kan det være billigere at miste meget af dem, hvis du laver et gendannet øjebliksbillede på for eksempel 6 måneder eller 1 år tidligere.
Recovery Time Objective
Dette er for at analysere og bestemme, hvor hurtigt gendannelsesoperationen kan udføres. Under gendannelse vil dine applikationer pådrage sig en vis nedetid, som også er direkte proportional med mængden af data, der skal gendannes. Hvis du gendanner et stort sæt data, vil det tage længere tid.
Database- og snapshotisolering
Isolation er et mål for, hvor tæt backup-snapshots er fra de primære databaseservere med hensyn til logisk konfiguration og fysisk. Hvis de tilfældigvis er tæt nok på, reduceres genoprettelsestiden på bekostning af øget sandsynlighed for at blive ødelagt samtidig med, at databasen ødelægges. Det er ikke tilrådeligt at hoste sikkerhedskopier og produktionsmiljøet i det samme system for at undgå, at afbrydelser på serverne også afhjælper sikkerhedskopierne.
Komplikationer med Sharding
For et distribueret databasesystem gennem sharding præsenteres en vis backupkompleksitet, og skriveaktiviteter skal muligvis stoppes på tværs af hele systemet. Forskellige shards vil afslutte forskellige typer sikkerhedskopier på forskellige tidspunkter. Overvejer logiske sikkerhedskopier og Snapshot-sikkerhedskopier,
Logiske sikkerhedskopier
- Shards har forskellige størrelser og vil derfor afsluttes på forskellige tidspunkter
- MongoDB-base dumps vil ignorere --oplog og vil derfor ikke være konsekvente ved hvert shard.
- Balanceren kan være slukket, mens den formodes at være tændt, bare fordi nogle skår måske ikke har afsluttet restaureringsprocessen
Sikkerhedskopier af øjebliksbilleder
- Fungerer godt til en enkelt replika fra version 3.2 og nyere. Du bør derfor overveje at opdatere din MongoDB-version.
Gendannelsesproces
Nogle mennesker udfører sikkerhedskopier uden at teste, om de vil virke i tilfælde af gendannelse. En sikkerhedskopi er i bund og grund at give en gendannelsesfunktion, ellers bliver den ubrugelig. Du bør altid prøve at køre sikkerhedskopierne på forskellige testservere for at se, om de virker.
Ydeevnefaktorer og tilgængelig lagerplads
Sikkerhedskopier har også en tendens til at tage mange størrelser som data fra selve databasen og skal komprimeres nok til ikke at optage en masse unødvendig plads, der kan skære ned på systemets samlede lagerressourcer. De kan arkiveres i zip-filer og dermed reducere deres samlede størrelser. Derudover kan man som før nævnt arkivere sikkerhedskopierne i forskellige datacentre fra selve databasen.
Sikkerhedskopier kan bestemme forskellige ydelser af databasen, idet nogle kan forringe den. I så fald vil kontinuerlige sikkerhedskopier give et vist tilbageslag, og bør derfor konverteres til planlagte sikkerhedskopier for at undgå udtømning af vedligeholdelsesvinduer. I de fleste tilfælde er sekundære servere installeret til at understøtte sikkerhedskopier. I dette tilfælde:
- Enkelte noder kan ikke sikkerhedskopieres konsekvent, fordi MongoDB bruger read-uncommitted uden en oplog, når man bruger mongodump-kommandoen, og i så fald vil sikkerhedskopier ikke være sikre.
- Brug sekundære noder til sikkerhedskopiering, da selve processen tager tid i henhold til mængden af involverede data, og de tilsluttede applikationer vil medføre en vis nedetid. Hvis du bruger den primære, som også skal opdatere Oplogs, så kan du miste nogle data under nedetiden
- Gendannelsesprocessen tager meget tid, men de tildelte lagerressourcer er små.
Fleksibilitet
Mange til tider vil du måske ikke have nogle af dataene under backup, som for eksemplet med Recovery Point Objective, kan man ønske, at gendannelsen udføres og filtrere brugerklikdataene fra. For at gøre det har du brug for en delvis sikkerhedskopieringsstrategi, der vil give fleksibiliteten til at filtrere de data fra, som du ikke vil være interesseret i, og dermed reducere gendannelsesvarigheden og de ressourcer, der ville have været spildt. Inkrementel sikkerhedskopiering kan også være nyttig, således at kun datadele, der er ændret, vil blive sikkerhedskopieret fra det sidste snapshot i stedet for at tage hele sikkerhedskopier for hvert snapshot.
Kompleksiteten af implementeringen
Din backupstrategi bør være nem at indstille og vedligeholde med tiden. Du kan også planlægge dine sikkerhedskopier, så du ikke behøver at lave dem manuelt, når du vil.
Konklusion
Databasesystemer garanterer "liv efter døden", hvis blot der er et veletableret backup-system på plads. Databasen kan blive ødelagt af katastrofale faktorer, menneskelige fejl eller sikkerhedsangreb, der kan føre til tab eller korruption af data. Før du laver en sikkerhedskopi, skal man overveje typen af data med hensyn til størrelse og vigtighed. Det er altid ikke tilrådeligt at opbevare dine sikkerhedskopier i samme datacenter som din database for at mindske sandsynligheden for, at sikkerhedskopierne bliver ødelagt samtidigt. Sikkerhedskopier kan ændre databasens ydeevne, derfor bør man være forsigtig med strategien, der skal bruges, og hvornår sikkerhedskopieringen skal udføres. Udfør ikke dine sikkerhedskopier på den primære node, da det kan resultere i systemnedetid under sikkerhedskopieringen og som følge heraf tab af vigtige data.