[ mrki @ 05.03.2004. 05:43 ] @
Dali postoji poseban postupak ili je dovoljno kopirati datoteke iz /nesto/mysql
Znaci hteo bi da prenesem bazu od nekih 15mb sa jednog hosta na drugi...
[ Gojko Vujovic @ 05.03.2004. 07:21 ] @
Kog tipa su tabele? Ako su myisam, zaustaviš server i prekopiraš ceo mysql/data direktorijum i poddirektorijume na novu lokaciju, gazeći stare fajlove i čuvajući permisije. Ako je innodb, onda zavisi gde si podesio da ti se nalazi njegov namespace.
[ B o j a n @ 05.03.2004. 09:36 ] @
Citat:
Gojko Vujovic:
zaustaviš server i prekopiraš ceo mysql/data direktorijum i poddirektorijume na novu lokaciju,


fantastique... i ljudi izmislishe mysqldump i bi dobro i videshe ssh pipe i odushevishe se...



[ Gojko Vujovic @ 05.03.2004. 11:37 ] @
Objasni koja je prednost mysqldumpa u njegovoj situaciji u odnosu na ovo što sam ja predložio?

Evo ti negativne strane - taj metod je znatno sporiji.
[ B o j a n @ 08.03.2004. 18:30 ] @
Zato sto na taj nacin mozes upasti u vrtlog vertikalne nekompatibilnosti mysql verzija. A pomocu mysqldump se obezbedjuje da dobijes uvek kompatibilan mysql dump baze.

Istina je da se nikome od nas to nije desilo zato sto mysql ( za sada ) ne pravi takav ne kompatibilan software, ali nikada se ne zna.
Ja sam se jednom na takav nacin opekao na psql sa 7.1 na 7.2... pa odatle moja paranoja....

[ Gojko Vujovic @ 08.03.2004. 23:00 ] @
Može biti .. ali kao što kažeš myisam tabele rade svuda isto tako da.. pitanje je vredi li. Jer posle dosta dugo vremena baktanja sa zvaničnim mysqldump i nezvaničnim mysqlhotcopy programima, primetio sam da imam najmanje glavobolja sa ovom najprostijom metodom - zaustavljanjem servera i kopiranjem mysql data direktorijuma. Ne može brže... ;)
[ caboom @ 09.03.2004. 00:02 ] @
u principu ste obojica u pravu, ali u zavisnosti od pocetnih uslova jedan je "pravlji" od drugog. mysql ti ne garantuje nikakvu binarnu kompatibilnost izmedju verzija, ali ako nista drugo takvi "dogadjaji" su obicno navedeni u CHANGELOG-u (da li moram da pomenem da niko ne garantuje da ce i tamo biti zapisana data informacija?). ako zelis da igras na sigurno onda moras da razlikujes ova 2 slucaja:
1) u slucaju da na oba servera imas apsolutno iste verzije mysql servera, mozes sasvim slobodno da iskopiras data dir (brze i jednostavnije).
2) u slucaju da imas 2 razlicite verzije pametno je da dump-ujes sadrzaj baz(e|a) koristeci mysqldump-a i potom da propustis generisani dump kroz mysql klijent (sporije, ali safe-play).
mysql zaista ima problema sa vertikalnom binarnom kompatibilnoscu i to nije mit. meni se licno, relativno davno, nekoliko puta desilo da mi se ovo pravilo potvrdilo. slican slucaj sam doziveo sa postgres-om i sybase-om.
[ Gojko Vujovic @ 09.03.2004. 00:38 ] @
Dobro, nikako nije problem vratiti backup na istu verziju mysql-a pa onda dumpovati do sutra ako se baš planira upgrade.
[ bluesman @ 09.03.2004. 03:21 ] @
Još jedna prednost myslqldump je što se rebuilduju indeksi pa nesvesno optimizuješ bazu (naročito važno kada je ogromna). U nekoliko slučajeva, kada nikakav repari nije pomogao i mysql stalno prijavljivao grešku na tabeli, mysqldump / drop / create / insert je savršeno odradio posao.
[ zi:: @ 09.03.2004. 06:33 ] @
Prenošenje baze prilično zavisi od veličine baze i vrste servisa. Ako je baza 15Mb, kao u ovom slučaju, svakako bih išao sa dumpom, prednosti su mnoge: optimizacija, čišćenje, zagarantovana kompatibilnost ...

Pre neki dan sam prebacivao bazu od 8Gb na drugi server (u pitanju su forumi/mailing liste), i nisam smeo preko dumpa (korisnici se ljute kada je servis nedostupan).

Ima jedna interesantna stvar: dešavalo mi se da prebacim preko dumpa MySQl bazu na jači server, a da baza bude osetno sporija (uprkos optimizaciji koja je urađena). Kasnije sam se setio da mysql ne uradi automatski analyze table ... na novim tabelama. Uprkos tome što je analyze table zahtevna komanda (za vreme izvršavanja je čak i read lock prisutan), toplo je preporučujem, jer su razlike u izvršavanju queryja drastične.
[ alex @ 09.03.2004. 10:34 ] @
Citat:
B o j a n:
Ja sam se jednom na takav nacin opekao na psql sa 7.1 na 7.2... pa odatle moja paranoja....


Da si procitao UPGRADE dokument video bi da te verzije nemaju kompatibilni format baze (na binarnom nivou).
[ mrki @ 14.03.2004. 01:20 ] @
Dakle ako sam dobro shvatio:
1.
prvo napravim backup (bez zaustavljanja servera)
#mysqldump --opt database > backup.sql
kopiram backup.sql na novi server i:
#mysql database < backup.sql
takodje bez zaustavljanja servera. Koristan nacin kada se vrsi upgrade servera.
2.
kopiranje baze sa jednog hosta (servera) na drugi:
#scp /var/lib/mysql/baza [email protected]_host:/var/lib/mysql/baza
s'tim sto je potrebno zaustaviti server i voditi racuna o tome dali su verzije servera identicne.
[ mrki @ 18.03.2004. 18:49 ] @
Jos jedno pitanje, da ne otvaram novu temu:

#mysqldump --opt database > backup.sql

Pretpostavljam da database mora da se kreira na novom serveru pre nego sto se importuju podaci sa starog servera, a tabele?
Znaci dali kod dump-a baze sa starog servera na novi server prenosim samo podatke (data) ili se pravi kopije cele strukture (svih tabela, promenljivih, veze...)

Koliko vremena je potrebno mysqldump-u da uradi backup baze recimo velicine kao sto je ova MB i dali je za vreme dumpa baza dostupna? Primetio sam u sitnim satima nekoliko puta:) dok se na elitsec. vrsi backup da forumi nisu dostupni...
[ Gojko Vujovic @ 18.03.2004. 20:25 ] @
Ne stoje pitanja, nema šta da razmišljaš da li će se nešto desiti samo od sebe ili neće (tipa da li će se dumpovati i struktura ili samo podaci), već to sam podesi tako što ćeš proslediti odgovarajuće parametre mysqldumpu prilikom dumpovanja ili podešavanjem my.cnf fajla. Ne treba ti bolja dokumentacija od ovoga (a čitanje i isprobavanje mogućnosti ove dve scripte će ti odneti najviše pola sata):

http://www.mysql.com/doc/en/mysqldump.html
http://www.mysql.com/doc/en/mysqlhotcopy.html

i obavezno štivo pošto ti izgleda nije sasvim ni jasna stvar sa lockovanjem:

http://www.mysql.com/doc/en/Backup.html