Databaser: sikkerhet og konsistens
Transaksjonar
Ein transaksjon er ein logisk samanhengande serie operasjonar som må gjerast samla for at databasen skal vera konsistent. Kron(!)-eksempelet er overføring frå ein konto til ein annan. Då må vi både trekkja pengar i fra-kontoen og leggja til tilsvarande i til-kontoen. (i verkeligheten er det meir komplisert). Hvis vi er halvveis så vil databasen vera inkonsistent. (vi har mista pengane)
Vi gir databasen beskjed om at ein transaksjon startar med START TRANSACTION eller BEGIN. Som default, kjører MySQL med såkalt autocommit. Det betyr at alle INSERT, UPDATE eller DELETE som du måtte gjera, oppdaterer databasen. Då er endringane permanente og kan ikkje rullast tilbake. I dette tilfellet kan vi betrakta kvar kommando som ein transaksjon. Når vi startar ein transaksjon beståande av fleire kommandoar vha START TRANSACTION vil autocommit bli slått av. Alle endringar i databasen blir då lagra i ein buffer. Når heile transaksjon gjekk ok, gjer ein COMMIT, og først då blir endringane utført (dvs. kopiert frå buffer til fil) i databasen. Hvis ikkje, gjer ein ROLLBACK. Det betyr at alle endringane i transaksjonen blir ignorert, og det skjer ingen oppdatering av databasen. Ein transaksjon som feilar blir normalt ikkje logga. ROLLBACK kan skje både manuelt og automatisk. Hvis for eksempel tilknytningen til databasen går ned midt i ein transaksjon, vil systemet utføra ROLLBACK av seg sjøl.
Backup
Databasar har som regel behov for regelmessige backups (sikerhetskopi). Då kan ein feks. dumpa heile databasen til ei fil. Ein database som er open for brukarar kan endra seg mens ein backup foregår. Vi har derfor to muligheter: enten stengja databasen eller å halda den open, men logga alt som skjer fra starten av backup til den er ferdig. Der første kallast ein kald backup. Då vil ingen oppdateringar vera mulig mens backup foregår, fordi den er stengt for brukarane. Den andre varianten kallast ein varm backup. (også kalla dynamisk backup) Dette vil vera nødvendig dersom det er kritisk at databasen er oppe, dvs. tilgjengelig for brukarane, 100% av tida. Hvis vi treng å bruka denne backupen, så må vi både lasta inn data som er lagra, og utføra dei endringane som er registrert i loggfila, for å få databasen slik den egentlig var då backupen slutta.
Når ein database skal restaurerast, vil SQL-serveren kopiera data og tilgjengelige transaksjonsloggar. Databasen blir først gjenskapt slik den var ved starten av backupen. Deretter blir eventuelle transaksjonar gjort på ny. I eksempelet over vil Trans 1 og Trans 2 bli gjort omigjen. Det betyr at data som vart endra av disse to transaksjonane vil finnast i den restaurerte databasen. Men (slik eg forstår det) vil ikkje Trans 3 og Trans 4 kunne gjerast påny fordi disse vart fullført etter at backupen var ferdig. Detaljane vedrørande dette må overlatast til spesialistane, men konklusjonen er i allefall at ein varm backup har fordeler i forhold til kald med hensyn på oppetide, men omkostningar i form av at den gjenskapte databasen muligens ikkje er heilt konsistent.
Kjelder:
What is the difference between cold backup and hot backup.
Backing up database files in offline mode (cold backup).