Backup podatkovnih baz

Odvisno od tipa baze, sistema, ki to bazo uporablja, in količine podatkov, ki se v bazi na enoto časa spremenijo. Malo bolj konkretiziraj te parametre, pa boš dobil bolj konkreten odgovor.

Hmnja... operacijski sistem je nepomemben, pomemben je INFORMACIJSKI sistem, ki bazo uporablja - predvsem njegove lastnosti, iz kateri izhaja kako, v kakšnem obsegu in s kakšno dinamiko se podatke v podatkovni bazi bere in spreminja.

MySQL je preveč široko: potrebna sta še konkretna verzija in mehanizem za shranjevanje podatkov, ker to bostveno vpliva na možnosti, ki jih imaš na voljo.

če se podatki konstantno spreminjajo in gre za kritične podatke ti predlagam, da si poleg backup-a baze sproti delaš še varnostno kopijo transaction log-a direktno iz aplikacije

Hmm... če imaš ISAM, potem PB ustavi in naredi kopijo datotek, če imaš InnoDB, potem ob primerni uri poženi "mysqldump --single-transaction". V enem primeru boš imel nadzorovano prekinitev delovanja, v drugem primeru pa povečano I/O obremenitev PB. Kaj dosti več v tej verziji MySQL ne boš mogel narediti, ne glede na vsa orodja, ki kje obstajajo. V 5.x bi lahko postavil še en strežnik in na njemu avtomatično izvajal vse transakcije, vendar pa tudi to ne bi bila najboljša rešitev, saj ti bi "poblaznela aplikacija" še vedno uničila podatke na obeh strežnikih (da ne bo kdo pozabil na to, da se ne varujemo samo pred odpovedjo strojne opreme).

Vsa 3rd party orodja se pri vseh DBMS-jih zanašajo na infrasturkturo, ki je že vgrajena v sam DBMS, dajo pa na voljo lepše oziroma bolj intuitivne grafične (spletne) uporabniške vmesnike. Če primerne infrastrukture ni, potem tudi orodja ne morejo narediti čudežev. Glede na to pa, da so taista orodja navadno naravnana ravno v uporabniške vmesnike, se jih praviloma ne da avtomatizirati, avtomatizacija pa je prvi, nujen in celo kritičen pogoj za pravilno delovanje vsake izdelave backup-ov. Če je potrebno karkoli delati ročno, bo človek vedno odnehal po X dnevih/mesecih/letih, če bo vse delovalo pravilno - stroj pa ne.

Pri mysqldump je bistveno kakšnega tipa je način shranjevanja podatkov na disku. Dve najbolj razišerjeni možnosti sta (my)ISAM in InnoDB. Pri ISAM ni dobro uporabljati mysqldump, ker ni nikakršnega zagotovila, da boš dobil konsistentne podatke (če želiš ti lahko dam tudi malo širšo razlago kako in zakaj), pri InnoDB pa boš dobil konsistenten pogled na podatke, vendar pa samo in samo v primeru, da je aplikacija, ki podatke spreminja, pravilno napisana.

Zato najprej preveri v kakšni obliki se podatki shranjujejo (storage type). Če je ISAM, potem brez ustavljanja strežnika verjetno ne bo šlo, če pa je InnoDB, pa je velika verjetnost, da boš dobil smiselne podatke, še posebej če se jih med 22h in 7h ne spreminja (varno okno za tovrsten backup). Brez pogovora s programerjem, pa ne bi računal na to, da bi lahko na ta način delal urne varnostne kopije - pojavijo se težave z razpoložljivostjo strežnika in z dvomi v konsistentnost podatkov.

Osnovna težava pri izdelavi varnostnih kopij pri MySQL je pa ravno izdelava shell skript (Bash je tvoj najboljši prijatelj), ki ti bodo na pravilen način naredile varnostno kopijo vseh podatkovnih baz, ki jih želiš zavarovati. Ko boš imel takšno skripto, pa jo samo še nastaviš v cron-u, ki ti jo bo lepo redno poganjal vsak dan ob pravi uri. Vsekakor si lahko pogledaš že narejene primere tovrstnih skript, ki so zelo dobro vodilo pri izdelavi lastnih, oziroma dobra osnova, če jih boš moral za svoje potrebe samo kaj popraviti/dopolniti. To je eden izmed bistvenih čarov filozofije odprte programske kode - vsekakor ga izkoristi.

Kar se tiče nadgradnje na 5.x pa tako: sicer boš z Enterprise različico lahko postavil rezerven strežnik, ki se bo lahko sprotno sinhroniziral z glavnim strežnikom, v primeru izpada glavnega, pa bo lahko prevzel tudi funkcijo glavnega. Vendar pa pazi, da boš še vedno delal varnostne kopije, ker te takšna postavitev zavaruje pred (fatalnimi) strojnimi napakami, nikakor pa ne pred programskimi napakami. Samo predstavljaj si, da začne aplikacija zaradi napake nekontrolirano brisati vse zapise v bazi. V takšnem primeru je vedno dobro imeti varnostno kopijo s katero lahko dobimo podatke iz nekega trenutka v preteklosti, ko so bili ti podatki še "nedotaknjeni". Res pa je, da boš lahko z rezervnim strežnikom v miru delal mysqldump tudi vsako uro, ali pa vsakih 15 minut (odvisno od hitrosti strežnika), pri čemer se to ne bo poznalo pri odzivnosti glavnega strežnika. Vendar pa pri tej možnosti še vedno ostane pogovor z programerjem, da preveriš, če lahko v času pisanja po bazi sploh narediš konsistentno varnostno kopijo (kako konsistentno in zakaj bi lahko dobil "slabo" varnostno kopijo ti lahko tudi razložim, če želiš).


Na koncu pa še malo osebnega godrnjanja, ki se tvojega problema načeloma ne tiče: MySQL je samo ena izmed možnih izbir za podatkovno bazo. Za nekatere namene odlična, za nekatere druge pa ne ravno optimalna izbira - pri pravilni uporabi pa vedno korektna. Kar me žuli je to, da se zunaj očitno potika veliko programerjev, ki ne, samo da ne znajo izbrati optimalne rešitve v danem trenutku za dan problem, teveč ne poznajo tudi osnovnih prijemov pri uporabi sodobnih DBMS. MySQL z InnoDB načinom shranjevanja je čisto solidno orodje, ki pa izgublja na vrednosti ravno zato, ker se ga vse prevečkrat lotevajo programerji, ki si tega naziva (še) ne zaslužijo. Na koncu pa vedno pade na DBA-je, da poskušajo rešiti, kar se rešiti še da, tudi kadar je aplikacija v bistvu zgrešeno napisana.

rsync

Za najlažji način prenosa datoteke iz računalnika A na računalnik B si odgovor že dobil. Trajanje pa je neposredno odvisno od pasovne širine, kar pomeni, da si ga lahko sam izračunaš iz dolžine datotek, ki jih pošiljaš in hitrosti povezave preko katere pošiljaš. Če te ne gane, da hraniš varnostne kopije na isti lokaciji (in računalniku) pa razmisli o kakšnem USB disku. Če ti odleti glavno diskovno polje, ti še vedno ostanejo varnostne kopije na dodatnem disku, če pa ti odleti ta disk, pa ga samo nadomestiš z novim.

Za konsistenco podatkov pa gre zgodba takole (trivialen hipotetičen primer z enim samim uporabnikom)
- zapiši dodaj novo vrstico v tabelo A [ INSERT INTO A(a1, a2, a3) VALUES ('v1.1', 'v1.2', 'v1.3') ]
- vedno, kadar je predhoden zapis uspešen, povečaj števec v tabeli B [ UPDATE B SET B1 = B1 + 1 ]

Ko uporabiš mysqlbackup, bo ta začel brati podatke iz hipotetične podatkovne baze, pri čemer lahko pride to naslednjega zaporedja:
Uporabnik: zapiši vrstico v tabelo A
MySQLDump: preberi podatke iz tabele A
MySQLDump: preberi podatke iz tabele B
Uporabnik: povečaj števec v tabeli B

Če privzamemo, da se morata števec v tabeli B in število vrstic v tabeli A na nek smiselen način ujemati, potem si pri zgornjem zaporedju dogodkov dobil nekonsistentno varnostno kopijo. Prebral si namreč vse podatke iz tabele A in vse podatke iz tabele B, vendar pa si s tem ravno na sredini prekinil delo uporabnika. Če boš takšno varnostno kopijo obnovil, boš imel v števcu, ki se nahaja v tabeli B napačno vrednost, saj si shranil samo "polovico" transakcije. Če pa prihaja do tovrstnih pojavov, pa to pomeni, da so (lahko) takšne varnostne kopije čisto neuporabne.


Sedaj pa nazaj k zgodbi z myISAM in InnoDB: Programer, če svoj posel obvlada, bo svoj postopek, ki mora biti bodisi v celoti zapisan, bodisi v celoti zavržen, označil kot eno transakcijo. S tem bo zagotovil, da bo ena transakcija "videla" samo tiste podatke, ki so bili že v celoti (ena celota je ena transakcija) obdelani in zapisani. Mysqldump to naredi z parametrom "--single-transaction" (naredi vse v eni transakciji - vse v enem nedeljivem koraku). To je pač način, da se (pod določenim pogojem) shranijo iz podatkovne baze podatki, ki so notranje konsistentni. Težava pa se pojavi pri ISAM načinu shranjevanja podatkov, saj ta oblika ne implementira transakcij. Te implementira samo InnoDB. Zaradi tega sicer lahko uporabiš mysqldump, vendar pa parameter "--single-transaction" ne spremeni ničesar, saj ISAM ne zagotavlja transakcijske semantike. To pa je tudi razlog za najhujše kritike MySQL strežnikov: ISAM je hitrer, vendar neuporaben za netrivialne sisteme, InnoDB je pravilno delujoč, vendar pa nič hitrejši od drugih alternativ, ki so "tako zelo počasne".

Kar se pa tiče določenega pogoja, pa je to nekaj, kar moraš izbezati iz programerja svoje aplikacije. Če programer razume transakcije, IN, če je programer svoja zaporedja SQL stavkov pravilno zaprl v transakcijske bloke, potem je z InnoDB zadeva rešena: z ustreznim parametrom pri mysqldump boš vedno dobil konsistentne podatke v varnostni kopiji. Če pa (kvazi) programer teh stvari ne pozna, izbira ISAM oblike zapisa pa je velikokrat (ne vedno!) signal, da teh stvari res ne pozna, potem tudi z InnoDB nisi ničesar pridobil, saj morajo vse aplikacije, ki dostopajo do PB spoštovati enaka pravila igre. Ker ISAM teh pravil ne podpira, pa jih programerji začetniki velikokrat izpustijo, če se jih sploh zavedajo.


Da pa bom pošten do vseh: obstaja veliko primerov, ko so podatkovne strukture, ki se jih v PB shranjuje tako enostavne, da so vsi SQL stavki trivialni, zaporedja stavkov, ki bi jih bilo potrebno varovati s transakcijskimi bloki, pa ne obstajajo. V takšnih primerih je ISAM oblika zapisa optimalna, ker je hitra, mysqldump pa bo vedno shranil konsistenten pogled na podatke. Ker pa je takšnih primerov v realnem svetu aplikacij precej malo, je teža dokaza, da je temu res tako, vedno na strani programerja in arhitekta aplikacije. Če takšnega dokaza ni, je za varnost podatkov najbolje, če se privzame najslabša možnost. Vedno pa se pri izdelavi načrta izdelave varnostnih kopij vrneš k programerju/programerjem, ki ti bodo edini znali dati odgovore, ki ti bodo omogočili izbrati optimalno rešitev. Poletje je tukaj, ob hladnem pivu na terasi pa se vsak jezik razveže.

Glede na to da ima MySQL in not kritične podatke je daleč najbolj primerna replikacija, vgrajena v MySQL, in sekundarni strežnik, ki se ves čas sinhronizira (ter redni backup na tem drugem strežniku, ki ne terja izpada servisa, ne glede na to kdaj se izvaja).