Fórum Root.cz
Hlavní témata => Server => Téma založeno: rado3105 18. 09. 2013, 16:36:00
-
Je mozne nejako zalohovat mysql databazu za behu? dakujem
-
man mysqldump
-
Mysqldump urobi nejaky dokument kde su prikazy na tvorbu tabuliek....alebo sa mylim?
Este som cital mysqlhotcopy...pouziva niekto?
Nie je nieco elegantnejsie ako rsyncy, bez toho aby som musel databazu vypnut?
-
automysqlbackup
-
Záleží, jaké máš konkrétní požadavky, jaké používáš enginy atd.
Máme velkou myisam + innoDB (desítky GB), jejíž dump trvá docela dlouho. Je potřeba zajistit konzistenci zálohy. Mohli bychom použít mysqldump s parametrem --single-transaction,ale ta se nevztahuje na myisam. Nebo klasicky zamknout tabulky, jenže takové zámky zaseknou aplikační server, když nebude moci dlouho zapisovat.
Osvědčila se nám master/slave replikace na jiný stroj, ten shodit a datový adresář zazálohovat rsyncem (cca 20 minut). Respektive shazujeme až druhý slave (tedy třetí v řadě), aby první slave byl pořád aktuální a kdykoliv jej šlo použít místo masteru. Aktualizujeme takto i DB pro vývojáře, aby měli minimálně každý den čerstvá data z produkce. Když si ji rozvrtají, během 20 minut mají čerstvou.
-
Osvědčila se nám master/slave replikace na jiný stroj, ten shodit a datový adresář zazálohovat rsyncem (cca 20 minut).
Samozřejmě jsem myslel shodit ten mysql server, ne celý stroj :)
-
Pokud klient aplikacim nevadi ze budou po cas zalohovani cekat, da se udelat totok:
na jedne konzoli spustit mysql commandline utilitu, a udelat: FLUSH TABLES WITH READ LOCK;
to flushne vsechny data na disk, a hodi read lock na vsechny tabulky.
Na druhe konzoli je mozne natvrdo zkopirovat vsechny data primo jako soubory, napr. z /var/lib/mysql/* nekam.
Zaloha z replikovaneho slave serveru, jak jiz bylo zmineno, je nejlepsi.
-
Souhlasím s Dustinem. My sice máme jen pár GB v MyISAm, ale děláme to vpodstatě stejně. Replikujeme, a 2x denně uděláme na slavu flush, zamkneme databázi na readonly, zkopírujeme soubory, odemkneme, a další databázi.
Nějaká komerční firma dělala nástroj, který fungoval přibližně tak, že normálně za běhu zkopíroval innodb databázi, a potom ji opravil na nějaký poslední bod, kdy byla konsistentní data. Detaily neznám.
-
Hm, ten flush se zámkem je daleko lepší než naše shození celé DB. Díky za inspiraci :-)
-
man mysqldump
Odpoved naprosto khownu ...
rado3105: Mysql zalohovat za chodu nelze, nedostanes konzistentni zalohu. Jinak viz ostatni - da se to ruzne obchazet, ale pokud chces realne mit zalohovanou databazi, kterou nemuzes vypnout, tak se budes muset ohlidnout jinde.
Jinak technicky - muzes pouzit nejaky FS ktery umi snapy, zamknout tabulky, vysypat cache a udelat snap, a odemnout je. Melo by to byt dostatecne rychly na to, aby si appky nevsimly. Ziskas tim backup binarnich souboru - nikoli dump, cimz zaroven ziskas daleko efektivnejsi moznost data obnovit. Obnovovat vetsi dump muze bejt na par hodin ...
-
Cestu přes snapshot fs jsem zkoušeli (LVM i btrfs), ale vždy tyto vrstvy způsobily výrazný pokles rychlosti DB, což byla pro nás konečná. Je to pár let, možná už je dnes btrfs jinde, ale tehdy to pro nás bylo fakt nepoužitelné.
-
Cestu přes snapshot fs jsem zkoušeli (LVM i btrfs), ale vždy tyto vrstvy způsobily výrazný pokles rychlosti DB, což byla pro nás konečná.
UFS na FreeBSD umí snapshoty nativně. Ale kvůli tomu asi OS měnit nebudete :)
-
A má jejich využití nějaký vliv na výkon FS? Je výkon takovéh snapshotového FS srovnatelný třeba s linuxovým XFS na srovnatelném HW? Fakt mě to zajímá, je to docela klíčové téma. Díky.
-
A má jejich využití nějaký vliv na výkon FS? Je výkon takovéh snapshotového FS srovnatelný třeba s linuxovým XFS na srovnatelném HW? Fakt mě to zajímá, je to docela klíčové téma. Díky.
Je to standardní FreeBSĎácký FS (FreeBSD má nativně jenom UFS a ZFS). Jaký je jeho výkon pro konkrétní účel na konkrétním HW, to by samozřejmě bylo nutné otestovat.
-
Díky za info.
-
Lze i za běhu s využitím tohoto:
http://www.percona.com/software/percona-xtrabackup (http://www.percona.com/software/percona-xtrabackup)
My to kombinujeme s rsyncem (i když to umí streamovat data na vzdálený server). Pár bash skriptů a crontab.
-
Aktualne narychlo som to poriesil cez quick backup v phpmyadmin..... nevyhody- treba to robit manualne, a je to moznu obnovit len pomocou phpmyadmin.
Percon xtrabackup vyzera zaujimave, ked sa to porovna s riesenim dastina co je lepsie pre mysql 5.5, a debian 7?
-
Omlouvám se za možná blbej dotaz, ale fakt je zálohování MySQL takovej problém? Věta "Mysql zalohovat za chodu nelze, nedostanes konzistentni zalohu." mě dost překvapila. To jako fakt? Já mám zkušenosti jen s MS SQL a tam stačí prostě příkaz BACKUP DATABASE... pro full backup nebo BACKUP LOG pro inkrementální zálohu logů. Případně to samý naklikat v GUI. V čem je u MySQL problém?
-
Omlouvám se za možná blbej dotaz, ale fakt je zálohování MySQL takovej problém? Věta "Mysql zalohovat za chodu nelze, nedostanes konzistentni zalohu." mě dost překvapila. To jako fakt?
V MySQL jsou příkazy nebo programy na backup, které fungují.
MySQL databáze (vlastně dokonce tabulka) jede buď na engine MyISAm nebo InnoDB. MyISAm není transakční, takže když se dělá backup, tak je potřeba zamknout celou databázi, provést backup, odemknout celou databázi (věřím, že příkaz backup to takhle udělá), a pak je backup databáze konzistentní. Ale ten backup trvá strašně dlouho, a databáze je uzamčená pro zápis, a to je často nepřijatelné. Proto je lepší zamknout, zkopírovat soubory, odemknout - rychlejší, ale pořád na nějaký čas zamčené, takže je ještě lepší rozjet replikaci a zálohovat slave - tam nevadí, že se na čas zamkne.
InnoDB je transakční, takže by problém s uzamčením neměl nastat, nemám to vyzkoušené, takže nevím, jak je to pak s výkonem.
Myslím (ale nemám to změřené), že backup a restore celých db. souborů je řádově rychlejší než backup příkazem backup.
Všechny tyhle metody jsou popsané v dokumentaci nebo na webu, ale pro začátečníka je asi složité důkladně si to důkladně pročíst vybrat si.
Zajímalo by mě: Jaký má u MS SQL serveru ten backup vliv na výkon? Čili, když mi běží backup, dá se server rozumně používat?
-
MyISAm není transakční, takže když se dělá backup, tak je potřeba zamknout celou databázi, provést backup, odemknout celou databázi (věřím, že příkaz backup to takhle udělá), a pak je backup databáze konzistentní.
Právě protože není transakční, tak backup nemusí být konzistentní, ne?
Když budu jednu hodnotu snižovat a druhou o stejnou velikost snižovat, tak nemám záruku, že na backupu bude součet pořád stejný, ne?
Na druhou stranu, když už někdo používá MyISAM, tak mu asi o konzistenci nejde.
-
MyISAm není transakční, takže když se dělá backup, tak je potřeba zamknout celou databázi, provést backup, odemknout celou databázi (věřím, že příkaz backup to takhle udělá), a pak je backup databáze konzistentní.
Právě protože není transakční, tak backup nemusí být konzistentní, ne?
Když budu jednu hodnotu snižovat a druhou o stejnou velikost snižovat, tak nemám záruku, že na backupu bude součet pořád stejný, ne?
Aha, takhle jsem se na to nedíval. Díky.
-
MyISAm není transakční, takže když se dělá backup, tak je potřeba zamknout celou databázi, provést backup, odemknout celou databázi (věřím, že příkaz backup to takhle udělá), a pak je backup databáze konzistentní.
Právě protože není transakční, tak backup nemusí být konzistentní, ne?
Když budu jednu hodnotu snižovat a druhou o stejnou velikost snižovat, tak nemám záruku, že na backupu bude součet pořád stejný, ne?
Na druhou stranu, když dělám tohle, tak bych si ty tabulky měl zamknout, jinak ta nekonzistence může vzniknout i z jiných důvodů, než je backup.
-
Na druhou stranu, když dělám tohle, tak bych si ty tabulky měl zamknout, jinak ta nekonzistence může vzniknout i z jiných důvodů, než je backup.
Měl no, ale známe praxi žejo :)
Prostě asi se shodneme na tom, že od netransakční databáze těžko očekávat konzistenci - ať už při provozu, pádu, nekorektním vypnutí nebo zálohování.
-
Viete mi poradit v skratke ako to riesit pre mysql 5.5, aby to robil cron, povedzme cez rsync. Je potrebne databazu zamknut, nie?
Je lepsie pouzit xtrabackup?
-
Sorry za flame, ale nemuzi si pomoct.
<flame>
MySQL databaze je tu uz 18 let a porad jeste nema online backup. 18 let to je hrozne dlouha dobe na SW produkt.
</flame>
PS: navic klon SQL, ktery pouziva MySQL je vubec nejvzdalenejsi vsem ANSI/ISO SQL standartum.
-
Omlouvám se za možná blbej dotaz, ale fakt je zálohování MySQL takovej problém? Věta "Mysql zalohovat za chodu nelze, nedostanes konzistentni zalohu." mě dost překvapila. To jako fakt? Já mám zkušenosti jen s MS SQL a tam stačí prostě příkaz BACKUP DATABASE... pro full backup nebo BACKUP LOG pro inkrementální zálohu logů. Případně to samý naklikat v GUI. V čem je u MySQL problém?
MySQL nema free nastroje na backup (pokud vim, je to soucasti placeny verze), to je jedna vec. Druha vec je, ze jak bylo zmineno, pouzivanejsi DB engine neni transakcni => konzistenci dat si musis zajistit jinak (na urovni aplikace). Ziskas tim samo vykon, ale na ukor bezpeci. A ani pouziti transakcniho engine != konzistentni databaze. Zalezi samozrejme na aplikaci, zda transakce pouziva a zda spravne. Ani M$ SQL ti nezajisti konzistentni data z pohledu aplikace, zajistit ti jen konzistetni databazi.
2Ivan: viz vejs, pokud vim, zalohovaci nastroje byly dycinky soucasti placeny verze.
BTW: Jinak co se tyce M$ SQL, zatizeni ... pri zalohovani, tak samozrejme zalezi predevsim na tom, kam se zalohuje a jak je nadimenzovanej srv/uloziste. Pokud ma srv dost RAMeti, a uloziste je slusne rychly pole, tak to na aplikacich nijak nepoznat. Ovsem standardni nastroje na zalohovani M$ SQL se defakto v realu vubec nepouzivaji. M$ SQL ma API, ktery se da zavolat zvenku, a bezne se zalohuje tak, ze nejakej klient nejakyho zalohovacicho systemu rekne serveru "krles" a ten pozastavi zapis do dat/dokonci tansakce. Pak zpatky rekne "OK" a zalohovac zacne odsypavat data. Pricemz SQLko vesele dal zapisuje do logu. Az zalohovac posle ze "hotovo", tak zacne SQLko aplikovat log do dat.
-
to Petr Blahos - dík za odpověď.
K MS SQL ... zajistit konzistenci dat z pohledu aplikace lze, pokud například převod z účtu na účet uzavřu do transakce:
BEGIN TRANSACTION; odeberu peníze z jednoho účtu; přidám peníze na druhej účet; COMMIT TRANSACTION.
Provede se buď oboje, nebo nic, i kdyby mezi tím zhavaroval server. Proto je to transakční databáze, aby to šlo zajistit.
Co se týče zálohování, tak opravdu záleží hlavně na výkonu disků. Pokud jsou slušně dimenzovaný s ohledem na velikost databáze, tak lze i při spuštěným backupu nebo restoru pracovat. Samozřejmě to ale zpomaluje. I u MS SQL je rychlejší vykopírovat přímo databázový soubory. Ani kvůli tomu se nemusí databáze vypínat, stačí udělat VSS snapshot file systému a soubor databáze a logu z něj (Předchozí verze souborů) vykopírovat. Konzistence dat je systémem zaručená. Ale tohle nevyužívá nijak často.
V praxi (větší síť) se opravdu zálogování SQLka volá z externího zálohovacího programu. Ten provede zálohu databází a výsledný soubory rovnou odleje na zálohovací server. Ve výsledku je to ale IMHO úplně stejný, jako zavolat backup přímo v SQL. Tak se to dělá u menších instalací. Buď se to nakliká v GUI jako maitenance plán, nebo se to pustí třeba jako baťák.
Ještě detail - ne každý ví, že Express verze SQLka je zdarma. Jediný reálný omezení je na velikost databáze (max 10 GB), databází může být samozřejmě víc. Max velikost využitelný paměti 1 GB taky nebejvá pro běžný projekty problém.
Ale to jsem trochu odbočil, nechci diskuzi od MySQL odvádět pryč, proto prosím žádný flame war.
-
Ještě detail - ne každý ví, že Express verze SQLka je zdarma. Jediný reálný omezení je na velikost databáze (max 10 GB), databází může být samozřejmě víc. Max velikost využitelný paměti 1 GB taky nebejvá pro běžný projekty problém.
Ale to jsem trochu odbočil, nechci diskuzi od MySQL odvádět pryč, proto prosím žádný flame war.
To je síce pekné, že M$ SQL Express je zdarma, na jeho prevádzkovanie ale potrebuješ nejaký stroj s M$ windows. Napríklad v mojej domácnosti máme spolu 4 počítače, ale takú nepraktickú zvrhlosť nemám ani na jednom z nich (ani ako virtuál).
-
1 % domácností si nainstaluje PostgreSQL. Výkon je menší než u MS SQL, ale konzistentní backup tam je defaultně.
-
...
Ad M$ express - je tam krom velikosti (a poctu databazi ...) jeste jeden, vcelku zasadni problem - je vyrazne (ale opravdu vyrazne) pomalejsi. +, jak bylo zmineno, je treba ty widle, a k nim prislusny CALy pro uzivatele ... ;D takze to zas tak "zadarmo" neni.
Jinak k zalohovani mozna jeste to, ze u zakaznika mame nasazeno zalohovani na urovni sektoru = zalohujou se zmeny (trvale) a SQLko se vola jen v okamziku, kdy je treba vyrobit konzistentni snap. Tudiz se pri tom prenasi jen relativne malo dat (v nasem pripade maximalne desitky MB). Navic si ten snap muzu obratem primontovat jako dalsi disk a klidne si z toho pripojit tu databazi a pouzivat ji (je to RW samo, ale snap jako takovej se nezmeni, pokud to pri odpojovani vylozene nechci).
-
1. není pravda, že je SQL Express pomalejší, jediné omezení je na 1 GB RAM, což stačí i na relativně velké databáze
2. žádné CALy nejsou potřeba
Omlouvám se za další offtopic, jen upřesňuju.
-
Odpovie mi prosim Vas niekto?
Funguje ten xtrabackup? Je to free?
Povedzme ze mi nevadi ked sa na par minut v noci vypne mysql - tak pointa zalohovania je ze to vypnem, zablokujem pristup a potom dane databazy zazalohujem cez rsync? Alebo?
-
Xtrabackup včetně celého sw od percony je zdarma, viz http://www.percona.com/, percona sama o sobě má spoustu vylepšení a lepší výkon. Na jejich webu je spoustu návodů a na netu taky. Případně doporučuji http://mysqlperformanceblog.com/, http://www.zmanda.com/backup-mysql.html. Jak již bylo výše zmíněno, nejlepší je zálohovat ze slave.
-
Po dlhsom case som sa k tomu dostal. Chce to riesit cez lock.
Urobil som si subor my.cnf, kde som vlozil:
[client]
user=root
password=xxx
Potom ked zadam v terminali: mysql -e "SHOW DATABASES"
pekne ukaze databazy...avsak ked zadam prikaz na zamknutie mysql, nezamkne:
mysql -e "FLUSH TABLES WITH READ LOCK"
tak ich nezamkne...ale ked sa prihlasim do mysql a zadam to pouzitim:
FLUSH TABLES WITH READ LOCK;
tak to funguje...
Potrebujem to z toho dovodu ze to chcem hodit do jedneho skriptu aj s rsyncom....
nieco na tento sposob, urobim subor: zaloha.sh, tam vlozim:
mysql -e "FLUSH TABLES WITH READ LOCK"
rsync -auAX --delete /var/lib/mysql/ /media/zalohy/ostatne/mysql/
mysql -e "UNLOCK TABLES"
exit 0
-
1. není pravda, že je SQL Express pomalejší, jediné omezení je na 1 GB RAM, což stačí i na relativně velké databáze
2. žádné CALy nejsou potřeba
Omlouvám se za další offtopic, jen upřesňuju.
Ale nemať tu lidi prosím tě ::)
Na widle na desktopu NESMÍŠ SQL Express nainstalovat, pokud se tam budou klienti připojovat vzdáleně, porušuješ licenci desktopového OS. Další omezení je v Agentovi, který je v Expressu vypnutý a zálohování je tak možné dělat jen přes onanovací baťák, stored proceduru nebo ručně.
Pěkný, budu muset vyzkoušet, obecně používám jen SQLdump a ještě se nestalo, že by se to po obnově nevzpamatovalo, nicméně taky neprovozujeme žádný kritický data.
-
Aby tu zase někdo neonanoval, že si tu honím triko a nepodložím to tvrzením:
Na widle na desktopu NESMÍŠ SQL Express nainstalovat, pokud se tam budou klienti připojovat vzdáleně, porušuješ licenci desktopového OS.
Tak třeba zde:
http://www.daquas.cz/articles/531-vse-co-potrebujete-vedet-o-uzivani-windows-8
Velmi populárním tématem v souvislosti s licencováním desktopového operačního systému je vystupování desktopového operačního systému Windows v roli serveru. Tato role je licenčními podmínkami pro desktopové operační systémy velmi omezená, bylo tomu tak u Windows 7, Vista i XP a nic se nezměnilo ani u Windows 8. Windows 8 tedy smí v roli serveru vystupovat pouze za účelem sdílení souborů, sdílení tisku, používání Internetové Informační služby, sdílení připojení k Internetu nebo telefonních služeb, a to pro maximálně dvacet dalších zařízení (u starších verzí Windows to bylo dokonce jen deset zařízení). Windows 8 tedy nesmí žádným způsobem figurovat například v roli databázového nebo aplikačního serveru, i když je to technicky možné. Není licenčními podmínkami povoleno na Windows 8 provozovat například poštovní server nebo databázový server s instalovaným SQL Serverem, ke kterému se připojují vzdálení uživatelé.
Omezené užití Windows 8 v roli serveru je povoleno především z důvodu možnosti tvorby domácí privátní sítě nebo velmi malé firemní sítě, kde uživatelé potřebují pouze sdílet soubory a dokumenty, popřípadě tisknout na společnou tiskárnu a přistupovat k Internetu přes jeden společný přípojný bod. Pokud ale potřebují využívat serverové aplikační systémy, jako jsou poštovní servery, databázové servery, ERP, CRM, nebo jen docházkové systémy, tedy aplikace typu klient-server, pak je pro serverovou stranu takového řešení skutečně nutné pořídit serverový operační systém, tedy Windows Server v některé z vhodných edic. Desktopový operační systém je určen pro stranu klientskou a jakkoli je technicky možné server rozběhnout na Windows 8, licenční podmínky takové užití zakazují, přesněji řečeno značně omezují, viz výše.
-
Je mozne nejako zalohovat mysql databazu za behu? dakujem
Omlouvam se za off topic, ale proste musim sdilet odkaz na lamera "muzu nejak stopnou zabehu ftp server?" (http://www.lamer.cz/quote/1) :D
-
Po dlhsom case som sa k tomu dostal. Chce to riesit cez lock.
Urobil som si subor my.cnf, kde som vlozil:
[client]
user=root
password=xxx
Potom ked zadam v terminali: mysql -e "SHOW DATABASES"
pekne ukaze databazy...avsak ked zadam prikaz na zamknutie mysql, nezamkne:
mysql -e "FLUSH TABLES WITH READ LOCK"
tak ich nezamkne...ale ked sa prihlasim do mysql a zadam to pouzitim:
FLUSH TABLES WITH READ LOCK;
tak to funguje...
Potrebujem to z toho dovodu ze to chcem hodit do jedneho skriptu aj s rsyncom....
nieco na tento sposob, urobim subor: zaloha.sh, tam vlozim:
mysql -e "FLUSH TABLES WITH READ LOCK"
rsync -auAX --delete /var/lib/mysql/ /media/zalohy/ostatne/mysql/
mysql -e "UNLOCK TABLES"
exit 0
Vie niekto preco to nejde?
-
No vyzera to byt silna kava aj pre tunajsich borcov...
viete poradit iny sposob ako sa cez skript prihlasit do mysql a spustit prikaz flush tables?
-
Nejjednodušší způsob je snapshot na úrovni souborového systému (LVM např.).
Nepoškodí se konzistence dat a systém bez jakéhokoliv přerušení běží dál, po ukončení zálohy se snapshot odebere.
-
rado>
Lock table ti nefunguje, protoze po ukoncenem spojeni do databaze MySQL uvolni ten zamek. Musel bys provest vsechny prikazy za sebou v ramci jedne session. Pokud se prihlasis do konzole, tak po provedeni prikazu, napr. lock table, je tabule zamcena dokud nezavolas unlock table nebo neukoncis pripojeni k mysql. Proto ti jedna varianta funguje a druha ne.
Jan Forman> Tohle nepomuze, protoze sice udelas obraz disku, ale to neznamena, ze MySQL nema nejaka data v pameti. Ikdyz udelas pred snapshotem flush tables, neznamena to, ze mezi porizenim snapshotu a flushnutim se neobjevili nejaka data v pameti.
Jinak pro backup jsou moznosti dve a to:
a)
Pokud je mozne, ze behem dumpu jsou tabulky read-only, tak lze udelat flush table s read lockem, pak dump a odemknuti (ale to musi byt vse v jedne session). Umi to takto mysqldump s prislusnym prepinacem...
b) Vytvori se mirrorovani mysql serveru (masteru) a dump se dela na slave. Na MySQL neni mirroring synchronni, tedy nez se prenesou data na slave to chvilku trva.
Pokud to neni opravdu velky projekt, na kterym jede sposta klientu, doporucuji variantu a) - je jednodussi a mas to hotove
za chvilku.
Honza
-
Nejjednodušší způsob je snapshot na úrovni souborového systému (LVM např.).
Nepoškodí se konzistence dat a systém bez jakéhokoliv přerušení běží dál, po ukončení zálohy se snapshot odebere.
Tohle může 100% fungovat jedině s InnoDB, která dokáže udělat recovery z transakčního logu.
Pro MyISAM to může skončit nefunkční zálohou - a ztrátou integrity db.
Záloha skrz snapshot simuluje havárii databáze - z které by se ACID databáze měly vzpamatovat - ale MyISAM není ACID a v případě havárie (nekorektního ukončení aplikace) můžete mít nekonzistentní databázi.
-
Je mozne nejako zalohovat mysql databazu za behu? dakujem
Omlouvam se za off topic, ale proste musim sdilet odkaz na lamera "muzu nejak stopnou zabehu ftp server?" (http://www.lamer.cz/quote/1) :D
Když už jsme u offtopiců z lamera, tak tenhle taky stojí za to:
http://www.lamer.cz/quote/71466
-
Muzete mi nekdo vysvetlit, proc nepostaci zalohovat repliku (slave)? To tu někdo pořád vymýšlí kolo?
-
Muzete mi nekdo vysvetlit, proc nepostaci zalohovat repliku (slave)? To tu někdo pořád vymýšlí kolo?
Jistě, protože tohle kolo může být kulatější než to tvoje kolo ;D
A taky to spotřebuje méně systémových prostředků ne?
-
Ano prihlasit sa do mysql dat locktables medzitym spusti rsync a potom unlock tables...je krasne rychle a jednoduche...len to chcem zautomatizovat..a nechapem ze by to nebolo mozne...nejaky interval wait, alebo take nieco? alebo spusti paralerne cez skript viacero prikazov a nech kazdy caka urcity cas, je to mozne?
-
Ano prihlasit sa do mysql dat locktables medzitym spusti rsync a potom unlock tables...je krasne rychle a jednoduche...
...zatímco spustit mysql dump je pomalé a složité nebo jak?
-
Nech som lovil ako som lovil, nevedel som cez mysqldump zazalohovat vsetky databazy...viete poradit? Ked to je take jednoduche?
-
viete poradit? Ked to je take jednoduche?
No já nevím, školy nemám, ale že by to byla opšna --all-databases ?
-
Takto robim manualne zalohu pre poistku v pripade ze zlyha mysqldump:
1.prihlasit sa do mysql:
mysql -u root -p
(zadat heslo na root)
2. zamknut databazu(odstavi to stranky vyuzivajuce mysql):
FLUSH TABLES WITH READ LOCK;
3. Zalohovat celu databazu cez tar(otvorte v novom terminali, ten terminal kde ste v mysql
nechajte bezat):
tar -czf /media/zalohy/ostatne/mysql/mysql-komplet-tar-manual_`date +%F`.tar.gz /var/lib/mysql
4. Po prebehnuti rsyncu odomknite databazu:
UNLOCK TABLES;
Staci cisto tar, alebo su potrebne na zachovanie aj nejake rozsirene atributy?