Citat:
SpizaGenije:
Naime, aplikacije radim na .net platformi, DB usvek naslanjam na MySQL server (PostgreSQL i MS SQL, samo ako je postojeća baza već na tim serverima). Access izbegavam i neću da radim sa njim. Ne mogu da kažem da to nije baza podataka, jer po definiciji
"Baza podataka je organizovan (ili neorganizovan) skup podataka na jednom mestu". Stoga nije greška reći i da je skup .txt fajlova u jednom folderu baza podataka, jer to zaista i
jeste baza podataka, ali nije
relaciona. Ali zato jeste
smeće!
baza podataka je i ormar sa index kartoncicima koji kazu gde se sta nalazi u biblioteci, no to, kao i cinjenica da cukas .not i ne koristis access a ponekad pgsql i m$sql nemaju nikakve veze sa bekapom mysql servera :D
Citat:
SpizaGenije:
Elem, većinom (gde god i kad god je to moguće), server se vrti na nekoj Linux mašini, klijent računari su na Win OS i nešto se ne sećam da imam bilo gde manje od pet mašina.
klijenti su potpuno nebitni, server ako nije linux moras ozbiljno da se preispitas zasto posto ma koliko od 5.5 na dalje mysql lepo radi na windoze serveru windoze ima mnogo nekih servisa (shadow copy, antivirus, antispy, anticovek, antinormalan, antisecurity, anti$@#%&@$) sa kojima mysql (jos uvek) ne ume da saradjuje tako da za bilo kakav ozbiljniji rad nije da windoza ne moze nego se bas bas ne isplati..
Citat:
SpizaGenije:
Do skoro (tačnije do pre nekih godinu i po', dve), bekap sam radio isključivo preko mysqldump, ali sam nailazio na sledeće probleme:
- minimum 5 klijent mašina, svaka minimum 30-ak puta u okviru sata odradi neki INSERT ili UPDATE (150 novih upisa ili izmena u bazi na sat vremena). Select me u ovoj priči oko bekapa i gubitka podataka ne interesuje.
- moram da radim bekap minimum svakog sata. Nije frka ako se desi neki kreš, pa uradim restore i izgubim podatke u poslednjih 15 - 30 minuta. Korisnik će ih uneti ponovo. Ali je problem za one klijent aplikacije koje kontrolišu PIC-ove, merne uređaje i slično i koje zapisuju vrednosti u realnom vremenu... Ti podaci se ne vratiše više nikada i onda izgubih konzistentnost podataka u bazi za taj period od par minuta.
ovako - NE MORAS DA RADIS BEKAP SVAKOG SATA :D
sta je fora, upalis binary log, uradis dnevno (u ponoc ili kad ti je vec najmanji load) mysqldump sa flush-logs, i kazes mu da ti zapamti poziciju i datum i to je to. naravno lock-all da bi imao konzistentan bekap. ako ti prsne baza u bilo kom trenutku imas dump + binary log, dakle dump ti je "osnovni" a binlog ti je inkrementalni bekap :D. Dodatno sta mozes da radis je da na 30min radis iz krona flush-logs i kopiras stari binlog na drugu masinu.
Citat:
SpizaGenije:
- radim bekap preko mysqldump, i imam LOCK baze na par sekundi/minuta. Nije problem za korisnika. Aplikacija "osluškuje" server baze i samu bazu, pošalje korisniku poruku i on zna (naučen iskustvom) da mora da sačeka sa radom par sekundi/minuta. Problem je sa onim aplikacijama koje komuniciraju sa uređajima, te moram da lovim na Try/Catch kroz aplikaciju i rešavam problem na drugi način (nebitan u ovoj temi i ovom podforumu), kako bih po otključavanju snimio/ažurirao podatke po tabelama.
abitno kako radis bekap, aplikacija koja prica sa bazom (bilo kojom) MORA da ume da hendla
- privreme greske
- trajne greske
- timeout
ako te tri stvari aplikacija ne ume da izhendla imas problem u aplikaciji!
Citat:
SpizaGenije:
Znam da će se neko naći i reći da je najbolja opcija dva (ili više) servera, VM, replikacija.
replikacija jeste resenje za mnoge stvari (ukljucujuci bekap). VM nije resenje ni za sta.
ako se u bazi nalaze korisni/potrebni/vredni podaci ne postoji izgovor za nemanje replikacije nevezano za nacin rada bekapa!!!!
Citat:
SpizaGenije:
Naravno da jeste, ali ovo su "niskobudžetna" rešenja, firme u kojima je rešenje implementirano ne bi ni primetile jaz jednom, ili dva puta godišnje od 15/30 min., a i da primete, ne bi ih tangiralo ni sekunde! Stoga, ne žele da se isprse, a realno - ne treba im!
to znaci da podaci nisu dovoljni bitni i ako nestane dan dva podataka pojeo vuk magarca, sta ima veze, pa ni samo pitanje bekapa nije strasno vazno
Citat:
SpizaGenije:
Samo na jednom mestu imam
tri servera (master/slave + backup) +
storage (8 HDDova na 15K + spare HDD - sve to na RAID 60) +
VM. Bilo (jako) potrebno, gubitak podataka značio katastrofu firmi od par desetina (možda i više) hiljada EUR i opet 3,14čke jedva nagovorio da se opruže...
bas sam juce nekom pisao, u srbistanu a i okolini u IT industriji ima posla i ljudi u IT industriji znaju da kvalitetnog coveka ne mogu da plate karamelama (cak ni toffi) tako da je trziste prilicno dobro, posla ima, veci problem je naci kvalitetne ljude i plate su ok. dakle u takvim situacijama imas 2 mogucnosti
1. nadjes drugi posao, kazes im da su neozbiljni i da neces da budes odgovoran sto ce sutra sistem da umre zato sto nisu hteli da daju 500eur za jos jednu masinu
2. ostanes na tom poslu ali
2a pripremis izvestaj sta je potrebno i sta ce sve moze da se desi ako to sve potrebno ne dobijes
2b trazis od odgovornog lica u firmi da potpise (digitalno ili na papiru) da je primio k'znanju doticne informacije
2c taj papir iskopiras, original ostavis doma a kopiju uramis i stavis u server sobu iznad db servera
sve ostalo je neprihvatljivo jer na taj nacin pravis problem i svima nama ostalima, onda bude "a spica je to pravio samo sa jednim serverom i radilo mu je, sta ce nama drugi server" i te fore
Citat:
SpizaGenije:
Čujem pre godinu/dve za Perkonin xtrabackup. Radi savršeno, bez problema - bekapujem kad 'oću i šta 'oću bez zaključavanja baze i ometanja rada.
radi super ali imas zakljucavanje, samo traje kratko :D
problem sa xtrabekapom je sto "kaska", znaci uvek kasnis nekoliko verzija, no obzirom na cenu to i nije neki veliki problem. takodje nema sve opcije koje ima meb ali opet, considering price.. :)
Citat:
SpizaGenije:
- xtrabackup vs. nešto vs. nešto drugo vs. ...
- mysqldump vs. nešto vs. nešto drugo vs. ...
- ostalo
1. ako imas bitne podatke mora imas replikaciju
2. ako imas server za replikaciju, bekap mozes na sve "jednostavne" nacine da radis na slave-u, jedino moras da vodis racuna o tome koliko slave kasni za masterom.
ja licno pravim bekap mastera za "bekap", slave je tu za failover i slicno
inace popularni nacini za pravljenje bekapa
0. u bilo kojoj kombinaciji binlog moze da se koristi za inkrementalni bekap
1. mysqldump (dolazi uz mysql)
pro - jedini pravi logicki bekap, taj bekap je jednostavno bilo gde importovati, editovati etc .. sansa da napravi bekap koji "ne valja" je minimalna, moze
con - mega giga turbo spor
side - tu postoji i myhotcopy koji je idealan za myisam i radi mega brzo extra dobar bekap, jedino sto myisam kao storage engine treba da UMRE!!! tako da to i nije bitan info
2. meb - MySQL Enterprise Backup (moze da se skine sa edelivery a licenxa kaze da moze da se koristi ako se uzme support subscription od orakla)
pro - online backup (bez ikakvog zakljucavanja), mega brz, mogucnost kreiranja inkrementalnog bekapa, extremno dobro testiran (postoji od kad postoji i innodb) i up2date sa zadnjim verzijama mysql servera
con - uslovi za koriscenje (mozes da ga "nelegalno" koristis tako sto skines potpuno funkcionalan nelimitovan "trial" sa edelivery ali da bi ga legalno koristio moras da imas subscription koji kosta 5k$ godisnje), pravi binarni bekap
3. xtrabekap - vrlo slican meb-u ali sa dosta manje funkcionalnosti, percona, free
pro - cena, vrlo brz bekap (xtradb lokuje sve tabele za pisanje, flushne sve na disk, ceka info od innodb-a da je ok da napravi snapshot i onda iskopira binarni bekap)
con - nije dovoljno testiran sa "najnovijim" innodb-om no ako se koristi sa xtradb serverom onda nije problem, obzirom na cenu to je skroz ok varijanta
4. mylvmbackup (bekap skripta koja koristi lvm funkcionalnost)
pro - cena (dzabe), extremno brz
con - zahteva da se datadir nalazi na lvm-u (sto i nije neki zahtev, datadir uvek treba staviti na lvm iz milion razloga), najveci problem kod lvmbekapa je sto pravi "crashed backup", dakle pre nego sto napravi lvm snapshot (koji onda bekapuje) mylvmbackup samo lokne i flushne sve na disk, nema mogucnost da "kaze" innodb-u da "prekine sa svojim background procesima" (sto meb ume) tako da ono sto dobijete kao bekap je kao da vam je u tom trenutku nestalo struje (malo bolje) tako da pri restore-u morate da reparirate datu (i mozda ...)
5. zmanda (i sve ostalo sto koristi zmanda agent kao sto je symantec netbackup)
pro - fancy interface, milion opcija
con - kosta ne malo para a, bem li ga, ja znam min 10 nasih klijenata koji placaju dobre pare koji su ostali bez bitne date zbog gresaka u zmanda bekapu, mozda je to sad ok ali ..
6. cdp (continuous data protection)
pro - fancy smancy nabildovan sistem
con - kosta puno para, ako se ne namesti kako treba (a to je extra jednostavno zabrljati) pravi neupotrebljiv bekap (prosli vikend je klijent prso, kazu da im je steta min milionce americkih dinara, i evo vec nekoliko dana developeri pokusavaju da extrahuju datu iz koraptovanog bekapa koji je napravio nedobro podesen cdp)
7. svi ostali snapshot sistemski bekapi (poput window shadow copy i ekipe)
pro - nema
con - NE RADI!!!! nemojte pokusavati uopste