Datakonsistens

Datakonsistens avser om samma data som lagras på olika platser stämmer överens eller inte.

Konsistens vid tidpunkten

Konsistens vid tidpunkten är en viktig egenskap hos säkerhetskopieringsfiler och ett kritiskt mål för programvara som skapar säkerhetskopior. Det är också relevant för designen av diskminnessystem, specifikt relaterat till vad som händer när de oväntat stängs av.

Som ett relevant backupexempel kan du överväga en webbplats med en databas som onlineuppslagsverket Wikipedia , som måste vara i drift dygnet runt, men som också måste säkerhetskopieras med regelbundenhet för att skydda mot katastrofer. Delar av Wikipedia uppdateras ständigt varje minut varje dag, medan Wikipedias databas lagras på servrar i form av en eller flera mycket stora filer som kräver minuter eller timmar att säkerhetskopiera.

Dessa stora filer – som med vilken databas som helst – innehåller många datastrukturer som refererar till varandra efter plats. Till exempel är vissa strukturer index som tillåter databasundersystemet att snabbt hitta sökresultat. Om datastrukturerna inte längre refererar till varandra på rätt sätt, kan databasen sägas vara skadad .

Motexempel

Vikten av punkt-i-tid konsekvens kan illustreras med vad som skulle hända om en säkerhetskopia gjordes utan den.

Anta att Wikipedias databas är en enorm fil, som har ett viktigt index som ligger 20 % av vägen och sparar artikeldata vid 75 %. Tänk på ett scenario där en redaktör kommer och skapar en ny artikel samtidigt som en säkerhetskopia görs, som görs som en enkel " filkopia " som kopierar från början till slutet av de stora filen(erna) och inte Överväg inte datakonsistens - och vid tidpunkten för artikelredigeringen är den 50 % komplett. Den nya artikeln läggs till i artikelutrymmet (vid 75 %-märket) och en motsvarande indexpost läggs till (vid 20 %-märket).

Eftersom säkerhetskopieringen redan är halvvägs klar och indexet redan är kopierat, kommer säkerhetskopian att skrivas med artikeldata närvarande, men med indexreferens saknad. Som ett resultat av inkonsekvensen anses denna fil vara skadad.

I det verkliga livet kan en riktig databas som Wikipedias redigeras tusentals gånger per timme, och referenser är praktiskt taget alltid spridda över hela filen och kan uppgå till miljoner, miljarder eller mer. En sekventiell "kopia"-säkerhetskopia skulle bokstavligen innehålla så många små korruptioner att säkerhetskopian skulle vara helt oanvändbar utan en lång reparationsprocess som inte skulle kunna ge någon garanti för att det som har återställts är fullständigt.

En säkerhetskopieringsprocess som korrekt tar hänsyn till datakonsistens säkerställer att säkerhetskopieringen är en ögonblicksbild av hur hela databasen såg ut i ett enda ögonblick. I det givna Wikipedia-exemplet skulle det säkerställa att säkerhetskopian skrevs utan den tillagda artikeln vid 75 %-märket, så att artikeldata skulle överensstämma med indexdata som tidigare skrivits.

Diskcachesystem

Tidpunktskonsistens är också relevant för datordiskundersystem.

Specifikt är operativsystem och filsystem utformade med förväntningar om att datorsystemet de körs på kan förlora ström, krascha, misslyckas eller på annat sätt sluta fungera när som helst. När de är korrekt utformade säkerställer de att data inte kommer att skadas på ett oåterkalleligt sätt om strömmen går sönder. Operativsystem och filsystem gör detta genom att se till att data skrivs till en hårddisk i en viss ordning, och lita på det för att upptäcka och återställa från oväntade avstängningar .

Å andra sidan, att strikt skriva data till disken i den ordning som maximerar dataintegriteten påverkar också prestandan. En process med skrivcache används för att konsolidera och sekvensera skrivoperationer så att de kan göras snabbare genom att minimera tiden som ägnas åt att flytta skivhuvuden.

Datakonsistensproblem uppstår när skrivcache ändrar sekvensen i vilken skrivningar utförs, eftersom det finns möjlighet till en oväntad avstängning som bryter mot operativsystemets förväntningar på att alla skrivningar kommer att utföras sekventiellt.

Till exempel, för att spara ett typiskt dokument eller en bildfil kan ett operativsystem skriva följande poster till en disk i följande ordning:

Journalanteckning som säger att filen XYZ är på väg att sparas i sektor 123.
Det faktiska innehållet i filen XYZ skrivs in i sektor 123.
Sektor 123 är nu flaggad som upptagen i register över ledigt/använt utrymme.
Journalanteckning som noterar att filen är helt sparad och dess namn är XYZ och ligger i sektor 123.

Operativsystemet förlitar sig på antagandet att om det ser att objekt #1 är närvarande (som säger att filen är på väg att sparas), men att objekt #4 saknas (bekräftar framgång), att lagringsoperationen misslyckades och därför borde den ångras eventuella ofullständiga steg som redan vidtagits för att spara den (t.ex. markera sektor 123 som fri eftersom den aldrig fylldes ordentligt, och ta bort eventuella poster av XYZ från filkatalogen). Den förlitar sig på att dessa objekt läggs till disk i sekventiell ordning.

Anta att en cachningsalgoritm bestämmer att det skulle vara snabbast att skriva dessa objekt till disk i ordningen 4-3-1-2, och börjar göra det, men strömmen stängs av efter 4 har skrivits, före 3, 1 och 2, och så dessa skrivningar förekommer aldrig. När datorn slås på igen, visar filsystemet att den innehåller en fil med namnet XYZ som finns i sektor 123, men denna sektor innehåller verkligen inte filen. (Istället kommer sektorn att innehålla skräp, eller nollor, eller en slumpmässig del av någon gammal fil - och det är vad som kommer att visa om filen öppnas).

Vidare kommer filsystemets lediga utrymmeskarta inte att innehålla någon post som visar att sektor 123 är upptagen, så senare kommer den troligen att tilldela den sektorn till nästa fil som ska sparas, i tron att den är tillgänglig. Filsystemet kommer då att ha två filer som båda oväntat gör anspråk på samma sektor (känd som en tvärlänkad fil ) . Som ett resultat kommer en skrivning till en av filerna att skriva över en del av den andra filen och osynligt skada den.

Ett undersystem för diskcache som säkerställer konsistens vid tidpunkten garanterar att i händelse av en oväntad avstängning skulle de fyra elementen skrivas på ett av endast fem möjliga sätt: helt (1-2-3-4), delvis (1, 1-2, 1-2-3), eller inte alls.

Avancerade hårdvarudiskkontroller av den typ som finns i servrar inkluderar en liten batteribackup-enhet på deras cacheminne så att de kan erbjuda prestandavinsterna med skrivcache samtidigt som risken för oavsiktliga avstängningar minskar. Batteribackup-enheten håller minnet strömförsörjt även under en avstängning så att när datorn startas upp kan den snabbt slutföra alla skrivningar som den tidigare har gjort. Med en sådan styrenhet kan operativsystemet begära fyra skrivningar (1-2-3-4) i den ordningen, men styrenheten kan bestämma att det snabbaste sättet att skriva dem är 4-3-1-2. Kontrollören ljuger i huvudsak för operativsystemet och rapporterar att skrivningarna har slutförts i ordning (en lögn som förbättrar prestandan på bekostnad av datakorruption om strömförsörjningen tappas), och batteribackupen skyddar mot risken för datakorruption genom att ge handkontrollen ett sätt att tyst fixa alla skador som kan uppstå som ett resultat.

Om strömmen stängs av efter att element 4 har skrivits, innehåller det batteribackade minnet registreringen av engagemang för de andra tre föremålen och säkerställer att de skrivs ("spolade") till disken vid nästa tillgängliga tillfälle.

Transaktionskonsistens

Konsistens (databassystem) inom området för distribuerade databassystem hänvisar till egenskapen hos många ACID- databaser för att säkerställa att resultaten av en databastransaktion är synliga för alla noder samtidigt. Det vill säga, när transaktionen väl har genomförts kan alla parter som försöker komma åt databasen se resultatet av den transaktionen samtidigt.

Ett bra exempel på vikten av transaktionskonsistens är en databas som hanterar överföringen av pengar. Anta att en pengaöverföring kräver två operationer: att skriva en debitering på ett ställe och en kredit på en annan. Om systemet kraschar eller stängs av när en operation har slutförts men den andra inte har gjort det, och det inte finns något på plats för att rätta till detta, kan systemet sägas sakna transaktionskonsistens. Med en pengaöverföring är det önskvärt att antingen hela transaktionen slutförs eller att ingen av den slutförs. Båda dessa scenarier håller balansen i schack.

Transaktionskonsistens säkerställer just det - att ett system är programmerat för att kunna upptäcka ofullständiga transaktioner när det slås på, och ångra (eller "rulla tillbaka") delen av eventuella ofullständiga transaktioner som hittas.

Applikationskonsistens

Applikationskonsistens, liknande transaktionskonsistens, tillämpas i större skala. Istället för att ha omfattningen av en enda transaktion måste data vara konsekventa inom gränserna för många olika transaktionsströmmar från en eller flera applikationer. En applikation kan bestå av många olika typer av data, olika typer av filer och dataflöden från andra applikationer. Applikationskonsistens är det tillstånd i vilket alla relaterade filer och databaser är synkroniserade och representerar applikationens verkliga status.