Fórum Root.cz
Hlavní témata => Server => Téma založeno: petersveter 03. 03. 2024, 18:02:47
-
Povedzme ze mam produkcnu db a idem aplikovat nejaku aktualizaciu aplikacie ktora bude menit data v db, napriklad premenovanie opravneni z "allow_foo" na "allow_bar" u vsetkych uzivatelov ktorych sa to tyka.
Vypnem teda aplikaciu, zalohujem db, aplikujem aktualizaciu, ak je vsetko v poriadku tak aplikaciu spustim. Ak nie, tak obnovim db zo zalohy a spustim aplikaciou znovu s nou, nez sa najde pricina chybnej aktualizacie.
Otazka je ako toto riesit? Mozem pousit mariadump/mysqldump ale to mi pride nie uplne idealne a tiez ani oficialna dokumentacia to neodporuca, pokial db nie je mala. Mozem skopirovat subory db, kedze viem kde na disku su, takze to je len otazka prace so suborovym systemom. Tiez mozem mat v samotnej aplikacii kod ktory bude suplovat mariadump, ale zase tam si neviem predstavit implementovat to uplne spravne, z casoveho hladiska, vzhladom na to ze musim riesit vsetky datove typy a spravne data detekovat a vyexportovat do niecoho, co potom viem aj opetovne spracovat pri importe).
Tak by ma zaujimalo co je taka najlepsia cesta? Bavime sa tu ale o vlastnej db, ziaden cloud alebo vzdialena db formou SaaS.
-
Mozem pousit mariadump/mysqldump ale to mi pride nie uplne idealne a tiez ani oficialna dokumentacia to neodporuca, pokial db nie je mala. Mozem skopirovat subory db, kedze viem kde na disku su, takze to je len otazka prace so suborovym systemom.
Kopírování databázových souborů rozhodně nedoporučuji. Dá se tím napáchat dost škody.
Jedním z řešení je mariadump/mysqldump. Nevýhodou může být, že se přitom zbytečně zálohují syntetické klíče, ale zpravidla to nevadí. Je to běžně používaná technika s minimem potíží a přežije to i upgrade databázového enginu.
Další možností je export do nějakého dokumentového stromu a jeho serializace. Je to o něco pracnější, ale umožňuje to zcela změnit typ nebo strukturu databáze.
Často používám techniku, že si otevřu transakci, provedu změny, vyzkouším, zda vše funguje a nakonec dám rollback. Ovšem v modelovém příkladu to asi nebude moc použitelné.
-
Pro podobné hrátky se mi velice osvědčilo mít DB (a nejen tu) na samostatném filesystému pod ZFS. Snapshot (příp. + clone) usnadňuje spoustu věcí i pro veliké databáze. Během okamžiku si ji můžeš ze snapshotu naklonovat a klidně na klonu spustit další instanci DB na otestování změn.
-
Kromě mysqldump-u se může použít mariabackup (myslím že je to něco jako Percona Xtrabackup). Udělá to v podstatě kopii db souborů online.
Funguje to OK, ale snapshot je nejspíš lepší volba z pohledu rychlosti, v případě že je možný vytvořit.
-
Kopírování databázových souborů rozhodně nedoporučuji. Dá se tím napáchat dost škody.
co je take strasne nebezpecne na cp /var/lib/mysql/foo /var/lib/mysql/foo_backup ?
-
Kopírování databázových souborů rozhodně nedoporučuji. Dá se tím napáchat dost škody.
co je take strasne nebezpecne na cp /var/lib/mysql/foo /var/lib/mysql/foo_backup ?
V první řadě bych měl mít shodný filesystem, resp. se shodnou velikostí blocků, což se ti občas nepovede, když to dáváš někam mimo. Bez vypnutého fast shutdown u innodb v kombinaci s velkým množstvím zápisů je pak i obnovení docela sranda (trvá dlouho než se zpracují logy). Snaphosty jsou lepší. Stejně tak ne všech situacích se řádně zavolá fsync a můžeš kopírovat stale data.
A co je na tom obecně špatně? Jakýkoliv backup, kde nemůžeš ověřit integritu dat je špatný backup, no a v tomhle případě nejsi nijak schopný ověřit integritu dat. Sice můžeš si udělat nějakých checksumy těch souborů, ale nevíš, jestli po spuštění bude vypadat samotná databáze shodně, protože nevíš v jakém stavu jsi to zkopíroval a jestli nedošlo k násilnému vypnutí nebo vynechání fsyncu.
Pokud není k dispozici snapshotable filesystem, tak za mě je ještě dobré řešení použít replikaci (pouze u innodb), udělat si slave databázi (ta bude tím backupem), rozpojit replikaci, spustit aplikaci a případně se vrátit ke stavu z slave databáze.
-
Tak riesit integritu suborov tu nema moc vyznam lebo to iste sa tyka zivej db takze ked je niekde nieco posr*** tak je to posr*** vsade a ci ide skopirovanu zalohu alebo zive data je irelevantne.
A na "snapshot" su prave veci ako https://mariadb.com/kb/en/storage-snapshots-and-backup-stage-commands/ ktore prave riesia kopirovanie na urovni suborov.
-
Tak riesit integritu suborov tu nema moc vyznam lebo to iste sa tyka zivej db takze ked je niekde nieco posr*** tak je to posr*** vsade a ci ide skopirovanu zalohu alebo zive data je irelevantne.
A na "snapshot" su prave veci ako https://mariadb.com/kb/en/storage-snapshots-and-backup-stage-commands/ ktore prave riesia kopirovanie na urovni suborov.
živej? Z toho, co jsi psal jsem pochopil, že jí vypneš.
Integrita zálohy je obecně důležitý údaj, zajišťuje, že se mi nic neztratí a ani nepřibude. A i u živých databází se dá řešit, viz třeba tvůj příklad s BACKUP STAGE.
Pozor, BACKUP STAGE řeší pouze innodb tabulky, neřeší třeba myisam, což jsou třeba medata o strukturách tabulek, uživatelů, hesel, procedur atd. Tvůj backup skript s tím musí počítat, není to plně transparentní.
-
Tak riesit integritu suborov tu nema moc vyznam lebo to iste sa tyka zivej db takze ked je niekde nieco posr*** tak je to posr*** vsade a ci ide skopirovanu zalohu alebo zive data je irelevantne.
A na "snapshot" su prave veci ako https://mariadb.com/kb/en/storage-snapshots-and-backup-stage-commands/ ktore prave riesia kopirovanie na urovni suborov.
živej? Z toho, co jsi psal jsem pochopil, že jí vypneš.
Integrita zálohy je obecně důležitý údaj, zajišťuje, že se mi nic neztratí a ani nepřibude. A i u živých databází se dá řešit, viz třeba tvůj příklad s BACKUP STAGE.
Pozor, BACKUP STAGE řeší pouze innodb tabulky, neřeší třeba myisam, což jsou třeba medata o strukturách tabulek, uživatelů, hesel, procedur atd. Tvůj backup skript s tím musí počítat, není to plně transparentní.
Zivej som mal na mysli ze ked vypnem db, a skopirujem subory, tak ak su poskodene skopirovane subory, najskor su poskodene aj zdrojove subory a teda cely disk je v p... a teda nema moc vyznam riesit nejaku integritu kedze mam vecsi problem. Jasne ze spravit nejaku hash kontrolu suborov ma zmysel, nehovorim ze nie, ale prislo mi ze tie argumenty zachadzali trosku do extremu ked niekto tvrdi ze kopirovat celu db do vedlajsieho priecinku ako zalohu je no-go.
-
Tak riesit integritu suborov tu nema moc vyznam lebo to iste sa tyka zivej db takze ked je niekde nieco posr*** tak je to posr*** vsade a ci ide skopirovanu zalohu alebo zive data je irelevantne.
A na "snapshot" su prave veci ako https://mariadb.com/kb/en/storage-snapshots-and-backup-stage-commands/ ktore prave riesia kopirovanie na urovni suborov.
živej? Z toho, co jsi psal jsem pochopil, že jí vypneš.
Integrita zálohy je obecně důležitý údaj, zajišťuje, že se mi nic neztratí a ani nepřibude. A i u živých databází se dá řešit, viz třeba tvůj příklad s BACKUP STAGE.
Pozor, BACKUP STAGE řeší pouze innodb tabulky, neřeší třeba myisam, což jsou třeba medata o strukturách tabulek, uživatelů, hesel, procedur atd. Tvůj backup skript s tím musí počítat, není to plně transparentní.
Zivej som mal na mysli ze ked vypnem db, a skopirujem subory, tak ak su poskodene skopirovane subory, najskor su poskodene aj zdrojove subory a teda cely disk je v p... a teda nema moc vyznam riesit nejaku integritu kedze mam vecsi problem. Jasne ze spravit nejaku hash kontrolu suborov ma zmysel, nehovorim ze nie, ale prislo mi ze tie argumenty zachadzali trosku do extremu ked niekto tvrdi ze kopirovat celu db do vedlajsieho priecinku ako zalohu je no-go.
o poškozených souborech na disku jsem vůbec nic nepsal. Ty důvody jsem ti tady vypisoval, zápis pro innodb mohl zůstat pouze v paměti a není uložen fyzicky na disku (soubory ib_logfile, ibdata, .frm a případně .ibd se mohou rozcházet), při kopírování tedy obraz nemusí mít konzistentní. Pokud bys ho chtěl mít je nejjistější z běžící databáze zjistit poslední transaction id a poté před kopírování čekat až v ib_logfile bude zapsané, to lze docílit třeba v kombinaci s tím backup stage.
V případě myisam to máš ještě blbější, protože ti databáze o tom moc neumí říct a ty soubory nemají žádný WAL, takže vypnout db, ručně ověřit, že vše je fyzicky zapsané, spustit na nich mysqlcheck/mariadb-check, pak zkopírovat. Myisam raději nepoužívám a interní struktury automatizuji, takže je vždy umím vytvořit znovu.
Ty problémy nejsou hypotetické, ale dost reálné. Ruční opravu databázových souborů z mysql/mariadb jsem dělal už mnokrát, záloha se udělala špatně a při nějakém DR se zjistilo, že databázi nelze spustit. Není to ojedinělý případ.
Stačí se podívat v jakém jsou stavu nástroje. U Mariadb https://mariadb.com/kb/en/how-mariabackup-works/ mají v dokumentaci řadu TODO, není moc rozsáhlá a v repu spousty issues. U mysql si zase za fyzický backup nechávají platit a ve free verzi není.
Pokud se na to musíš ptát, je lepší to nedělat, ten proces není tak přímočarý jako zkopírování souborů a může se vymstít při obnově.
-
Ja nehovorim ze nevies o com hovoris, ale myslim ze vychadzas z predpokladu ze DB bezi, inak hovorit o tom ze nieco ostane v ramke a nie je zapisane nedava moc zmysel. Jasne ze sa da zalohovat aj "za behu", ale to neriesim a dufam ze ani nikdy nebudem musiet riesit. Ja cely cas hovorim o vypnutej DB, tak preto mi to prislo dost podivne.
Anyway, z vyssie uvedenych prispevkov mi prislo teda ze ked sa bavime o vypnutej DB, najlepsie je proste skopirovat celu zlozku s DB, idealne aj zbehnut nejaky checksum.
Takze by som to asi uzavrel, co sa MariaDb/MySQL tyka.
Ale len zo zvedavosti by ma este zaujimalo, ci je situacia odlisna napriklad pri Postgres?
-
Maria/mysql zalohovat neumi, nikdy neumela a nejspis nikdy umet nebude. Takze ti stejne nezbyva se smirit s tim, co mas.
Cast toho proc je to nafigu tu popsal _Tomáš_ .
U libovolny databaze je principielne treba resit
1) konzistenci na urovni souboru = databaze soubor zvlada cist/zapisovat. Ta bude nejspis OK, pokud tu databazi korektne vypnes.
2) konzistenci na urovni databaze = tabulky a jejich polozky jsou citelny, nechybi ... . Zase, pokud databazi korekne vypnes, nejspis to bude OK.
3) kozistenci na urovni aplikacni logiky. K tomu ti vypinani databaze nepomuze. Jinak receno, kdyz tu databazi vypnes v okamzeni, kdy aplikace neco zapisuje, tak tam proste budes mit dat pulku - napriklad jen polozky bez hlavicek.
Aby to vsechno fungovalo, musis mit databazi ktera zalohovat umi, a taky autora aplikace, ktery neni blb, coz je vzacnejsi nez kupka v jehle. Pro priklad viz DiPSy, kde ti tupci nezvladaji unikatni zaznam.
-
Pokud máte k dispozici souborový systém se snapshoty, použil bych vytvoření snapshotu. Ten samozřejmě musíte dělat v okamžiku, kdy jsou data na disku konzistentní – tedy buď při zastavené databázi, nebo se dodělávala podpora (obecně do OS a aplikací) pro to, že můžete databázi říct, že teď má všechna data zapsat na disk, databáze pak pošle signál, že je vše zapsané a dál nezapisuje, pak se udělá snapshot a pak se databáze odemkne pro další zápis. Tj. dá se udělat konzistentní snapshot i za běhu databáze. Ale nevím, zda MariaDB tuhle funkcionalitu podporuje.
Pozor také na to, že dříve byly problémy s výkonem databází na CoW systémech – protože databáze byly optimalizované pro systémy, které data na disku přepisují. Jednak už se to asi zlepšilo, je možné, že se databáze umí trochu přizpůsobit CoW systému. Ale hlavně u té vaší databáze nepředpokládám nějaké extra velké nároky na výkon.
Když už máte udělaný konzistentní snapshot, můžete si s ním dělat, co chcete – třeba nad ním spustit jinou instanci databáze, ověřovat konzistenci nebo vyexportovat data a připravit je pro import do souborového systému s jinou velikostí bloků, tedy cokoli z toho, co by chtěl _Tomas_ (a vy pravděpodobně nechcete, protože chcete mít jen zálohu dat pro případnou obnovu na tomtéž stroji a souborovém systému).
-
Maria/mysql zalohovat neumi, nikdy neumela a nejspis nikdy umet nebude. Takze ti stejne nezbyva se smirit s tim, co mas.
Cast toho proc je to nafigu tu popsal _Tomáš_ .
Jasne, ved ono zase to nie je uloha DB aby "sama seba" vedela zalohovat. Ale tak zase su tu aj alternativy ako mysql-kompatibilna titanium db alebo pgsql-kompatibilna cockroach db. Oboje v principe funguju uplne rovnako, nad kvdb, a su skalovatelne a "moderne". Ale myslim ze obycajna maria/mysql toho zvladne viac nez dost, zatial.
PS: vidim ze v prvom prispevku som napisal "vypnem aplikaciu", takze z toho vzniklo najskor to nedorozumenie ze db bezi nadalej. Takze nie, nebezi, mal som na mysli ze proste je vsetko vypnute, vratane db. Spravim zalohu, spustim db, aplikujem aktualizaciu, overim ze je vsekto ok a potom bud spustim aplikaciu alebo revertnem na povodnu db.
-
Ja nehovorim ze nevies o com hovoris, ale myslim ze vychadzas z predpokladu ze DB bezi, inak hovorit o tom ze nieco ostane v ramke a nie je zapisane nedava moc zmysel.
Linux kernel může držet zapsaná data v paměti a mariadb si při ukončení nemusí vynutit jejich fyzické zapsání na disk, při záloze, pokud následuje v rychlém sledu po vypnutí, podle způsobu jak jí provedeš můžeš přečíst původní data a ne ty čerstvě zapsané.
Viz mariadb a nastavení innodb_flush_method nebo třeba man page z linuxu https://man7.org/linux/man-pages/man2/fsync.2.html.
Očividně neznáš řadu tehle funkcionalit (to není špatně, nikdy nezná vše), proto je ale pro tebe bezpečnější se vyhnout kopírování souborů než se to naučíš.
Ale len zo zvedavosti by ma este zaujimalo, ci je situacia odlisna napriklad pri Postgres?
Tam je to jednodušší, jednak má nástroj pg_basebackup, který v umí tohle dělat a zajistí ti všechny potřebné kroky a jednak má jednodušší struktury a snadnější ověření binárních souborů, že jsou v pořádku. Nemá neustále přepisované soubory jako má myisam engine.
-
Nejak si neviem predstavit ze by Maria/Mysql mohli byt vypnute a mat poskodene data tym ze nezbehne fsync alebo nieco podobne. To mi pride ako nejaka extremna situacia.
PGSQL znie lepsie ale je to pre mna neschodne riesenie kedze cely zivot pouzivam mysql a prepisat sql a schemu pre pgsql by bolo casovo narocne(uz som pgsql skusal ale prave tie rozdiely ma vzdy odradili z jej pouzivania, tiez absencia dobreho gui). Ale aspon je dobre vediet ze pgsql ma priamo nejaky nastroj. I ked ono by sa dalo polemizovat ze maria ma prave ten BACKUP STAGE ktory funguje totozne takze pgsql nie je v nicom odlisna tym padom a ide skor len o akysia individualny bias? Plus myisam dnes uz naozaj nikto nepouziva.
A tiez je tu percona a xtradb ako dalsia alternativa pre mysql a innodb a tiez ma xtrabackup. Takze mysql/maria/percona ma stale co povedat si myslim.
-
Nejak si neviem predstavit ze by Maria/Mysql mohli byt vypnute a mat poskodene data tym ze nezbehne fsync alebo nieco podobne. To mi pride ako nejaka extremna situacia.
PGSQL znie lepsie ale je to pre mna neschodne riesenie kedze cely zivot pouzivam mysql a prepisat sql a schemu pre pgsql by bolo casovo narocne(uz som pgsql skusal ale prave tie rozdiely ma vzdy odradili z jej pouzivania, tiez absencia dobreho gui). Ale aspon je dobre vediet ze pgsql ma priamo nejaky nastroj. I ked ono by sa dalo polemizovat ze maria ma prave ten BACKUP STAGE ktory funguje totozne takze pgsql nie je v nicom odlisna tym padom a ide skor len o akysia individualny bias? Plus myisam dnes uz naozaj nikto nepouziva.
A tiez je tu percona a xtradb ako dalsia alternativa pre mysql a innodb a tiez ma xtrabackup. Takze mysql/maria/percona ma stale co povedat si myslim.
docela snadno, stačí třeba v systemd službě mít TimeoutStopSec>0 (či obdobu v dockeru) a vypnutý fast shutdown, pak se nemusí vše řádně stihnout. Mít starší verzi mariadb s O_DSYNC, kde to dělalo občas problémy a fsync se při vypnutí nevolal. Stejně tak mít O_DIRECT a vypnutý innodb_use_native_aio (což kvůli bugům je automaticky na některých kernelech, ikdyž ho v configu zapneš), pak nezapsaná data zůstávají v innodb bufferech. Mariadb ještě docela nedávno neuměla oddělit fsync metadat a dat, takže volala obě najednou, což je drahé a tak se tím šetřilo. Takže pozor na to, je to občas docela alchymie. Teď to celé strč do kombinace s nějakým overlayfs, protože ti přišlo skvělé to spustit v dockeru.
Povinná metadatová databáze "mysql" je v myisam enginu, to k tomu nepoužívání, pokud jí změníš na innodb, což lze, tak občas něco nepěkně selže. Mariadb je neskutečně zákeřná tím, že má řadu archaických částí a kódů. BACKUP STAGE je dobrá funkce, řeší to právě řadu těch problémů, o kterých jsem psal. Nepřitomnost oficiálního nastroje na fyzický backup, strohá oficiální dokumentace je něco, co by ti mělo spustit v hlavě červenou kontrolku, že tady je něco špatně.
Doporučuji dělat backup přes replikaci (galera nebo klidně asynchronní nativní) a metadata, která jsou v mysql databázi si držet bokem či na ně používat mysqldump.
xtrabackup je depracated, stejně jako celé xtradb, to už se dále nevyvíjí. Stejně tak i tokudb a nově se všichni soustředí na myrocks (ironie: jsem zvědavý co ho za pár let nahradí).
Mysql/Mariadb se dlouhé roky snažili získat jakkoukoliv výhodu, aby byly rychlejší, takže vše je postavené na tenkých základech, používají spoustu hacků, spousty triků za cenu nespolehlivosti a složité obsluze. Postgresql raději jde méně efektivní cestou (z hlediska cpu, ram), ale je zpravovatelnější, jeho chování očekávatatelné a celkově se s ním lépe pracuje. Jako UI je dobré od Jakuba Vrány Adminer. Přechod znamená nějakou práci a učení, ale dlouhodobě se ti asi vyplatí.
Tak dlouho jsem se snažil udržet mysql/mariadb stabilní až mám dnes nejvíce zakázek právě v opravě rozbitých databází.
-
docela snadno, stačí třeba v systemd službě mít TimeoutStopSec>0 (či obdobu v dockeru) a vypnutý fast shutdown, pak se nemusí vše řádně stihnout. Mít starší verzi mariadb s O_DSYNC, kde to dělalo občas problémy a fsync se při vypnutí nevolal. Stejně tak mít O_DIRECT a vypnutý innodb_use_native_aio (což kvůli bugům je automaticky na některých kernelech, ikdyž ho v configu zapneš), pak nezapsaná data zůstávají v innodb bufferech. Mariadb ještě docela nedávno neuměla oddělit fsync metadat a dat, takže volala obě najednou, což je drahé a tak se tím šetřilo. Takže pozor na to, je to občas docela alchymie. Teď to celé strč do kombinace s nějakým overlayfs, protože ti přišlo skvělé to spustit v dockeru.
Povinná metadatová databáze "mysql" je v myisam enginu, to k tomu nepoužívání, pokud jí změníš na innodb, což lze, tak občas něco nepěkně selže. Mariadb je neskutečně zákeřná tím, že má řadu archaických částí a kódů. BACKUP STAGE je dobrá funkce, řeší to právě řadu těch problémů, o kterých jsem psal. Nepřitomnost oficiálního nastroje na fyzický backup, strohá oficiální dokumentace je něco, co by ti mělo spustit v hlavě červenou kontrolku, že tady je něco špatně.
Pokud nedokážete databázi korektně vypnout, máte problém tak jako tak. Narazíte na něj minimálně při aktualizaci jádra a restartu systému, nebo při nutnosti vypnout server (třeba při výpadku napájení). Takže já bych nejprve vyřešil to, jak korektně vypnout databázi, a pak už můžete použít snapshoty nebo kopii datových souborů.
-
...
Dobre info 👍🏻
-
Jasne, ved ono zase to nie je uloha DB aby "sama seba" vedela zalohovat.
To se prave pletes. Databaze musi umet zalohovat, nikdo jiny to za ni neudela. Normalni databaze ma nejaky vlastni system zalohovani + ma api, ktere muze volat externi zalohovac.
A funguje to tak, ze ty reknes databazi "deme zalohovat", databaze ti rekne "moment" ... dokonci bezici transakce (tady prichazi kamen urazu s tupym vyvojarem aplikace), a teprve pak ti rekne "krles". Nacez ty ji samozrejme ve finale sdelis, ze "hotovo". Databaze zaroven potrebuje vedet ze byla provedena zaloha, treba proto aby ty transakcni logy mohla vymazat.
Samozrejme se pocita s tim, ze se databaze (kazda normalni) zalohuje za behu. A proto napriklad je vrele doporucovano mit transakcni logy na jinem disku nez data, protoze prave do transakcniho logu databaze zapisuje po dobu kdy bezi zalohovani. A ty tudiz nechces treba prostrednicvim snapshotu vyrabet nekonzistentni zalohu transakcniho logu.
Tohle maria/myslq neumi. To sice neznamena, ze se neda pouzit na nejaky srandaweby, ale pro nasazeni u aplikaci kde nechces prijit o data je vazne zcela nepouzitelna.
-
jjrsk:
Ehm, imho to vidíš příliš složitě. Dobrá databáze s rozumnou architekturou (např. generační) a tedy rozumně řešenou transakční izolací nic takového nepotřebuje, protože různé transakce mohou vidět různou "verzi" databáze. A prostě zálohování proběhne v jedné transakci, která vidí stav (commitovaných) dat k jednomu danému okamžiku - a nic více prostě k jednorázové záloze nepotřebuješ. Mám pocit, že tady polovina lidí a postů řeší rovnáky na vohejbáky MySQL, a zobecňuje je na databáze obecně.
Takže MySQL to možná neumí, ale rozumné db (např. PostgreSQL) to nepotřebují. Ne, že by takovou funkcionalitu neměla, ale ta slouží nikoli k jednorázové záloze, ale k záloze, na kterou jdou následně přehrávat WAL logy, což je oproti tomu, co se zde řeší, vyšší dívčí.https://www.postgresql.org/docs/current/continuous-archiving.html (https://www.postgresql.org/docs/current/continuous-archiving.html)
==
Stejnětak u rozumné databáze po vypnutí není problém kopírovat soubory (viz např.:https://www.postgresql.org/docs/current/backup-file.html (https://www.postgresql.org/docs/current/backup-file.html)) (https://www.postgresql.org/docs/current/backup-file.htmlproto), protože databáze po vypnutí prostě pošle všechna data kernelu, a jestli to je nebo není flushnuto kernelem na disk při kopírování souborů nijak nevadí. To, že při kopírování souborů musím počkat, až proces databáze reálně skončí (a ne spoléhat na to, že jsem mu řekl: "chcípni") je samozřejmě samozřejmost.
-
Logik, vidim to podobne. Ale zacinam sa priklanat na stranu nasadenia pgsql. Nie vsade, ale na par konkretnych write-heavy aplikacii mi to zacina celkom davat zmysel.
-
Použití PostgreSQL rozhodně doporučuju, chová se to prostě jako normální databáze. Použít pak btrfs snapshoty a spustit databázi nad starším snapshotem je pak triviální (když to máte správně připravené), jak popisuje třeba Heron v BTRFS v praxi po 5 letech: PostgreSQL (https://www.heronovo.cz/btrfs-praxi-po-5-letech/#:~:text=dal%C5%A1%C3%AD%20%C5%A1%C5%A5avnat%C3%A9%20p%C5%99%C3%ADklady.-,PostgreSQL,-Vlastn%C4%9B%20analogie%20v%C3%BD%C5%A1e). Nebo je to popsané přímo v dokumentaci PostgreSQL: File System Level Backup (https://www.postgresql.org/docs/current/backup-file.html).
-
Přesně to samé provozuji s mariadb + ZFS. Proč by to nemělo fungovat, vždyť je přímo v tom popisu napsané, že db musí být shozená?
-
Přesně to samé provozuji s mariadb + ZFS. Proč by to nemělo fungovat, vždyť je přímo v tom popisu napsané, že db musí být shozená?
Pokud bude databáze zastavená, bude to fungovat s jakoukoli databází, která neztrácí data při každém vypnutí. Mezi tím se ale diskutuje o tom, že se to dá dělat i bez shozené databáze – pokud se ta databáze chová jako normální databáze a pokud vám nevadí, že se to bude chovat jako třeba při výpadku napájení. Tj. pořád budete mít databázi ve stavu, že je tam zapsaná poslední potvrzená transakce, ale náběh bude třeba chvilku trvat (protože se musí přehrát potvrzené ale nezpracované transakce).
-
petersveter: Upřímně, pokud máš potřebu řešit takovéto věci na fóru, tak bych se hodně divil, kdybys dělal aplikace takového rozsahu, že by mělo smysl použití MySQL. MySQL podle mých skromných zkušeností může mít smysl tam, kde se jde výkonem tak na hranu, že občas "špinavá" architektura MySQL může přinést rychlost, kterou robustní Postgresql mít z principu nemůže - a už to nejde "dohnat železem". Ale dokud to jde dohnat železem, tak problémy, které s PostgreSQL nemusíš řešit, budou vždy levnější, než to "železo". (Pak se ještě občas se narazilo na nějakou featuru, kterou PostgreSQL neměla, ale mám dojem, že to byla minulost, že už se postgreska víceméně vše co "normální člověk potřebuje" naučila).
Pravda, od MySQL jsem utekl už dávno, a měl bych velkou averzi se vracet, takže ber můj pohled jako "poněkud zaujatý" a možná ne úplně reflektující současný stav MySQL (byť zkušenosti lidí co tu napsali my jen potvrzují mé starší zkušenosti), ale zas si nemyslím, že je tak mimo.
Tzn.: bejt Tebou, tak se naučím postgresku a přemigruju všechno, co jde.
-
Logik, vidim to podobne. Ale zacinam sa priklanat na stranu nasadenia pgsql. Nie vsade, ale na par konkretnych write-heavy aplikacii mi to zacina celkom davat zmysel.
Předem si to vyzkoušejte. PostgreSQL má jinou implementaci MVCC a jiný formát tabulek a indexů než MySQL a pokud máte opravdu write heavy aplikace , tak se Vám MySQL bude pravděpodobně chovat lépe. Moje zkušenost je taková, že Postgres je perfektní databáze, která dobře zvládá aplikace eshop, účetnictví, .. ale aplikace ve smyslu agregátorů - mám množinu slov, a pro každý klik na slovo na českém internetu udělá inkrementaci, tak to není to pravé ořechové. Jednak pro tento case jsou speciální databáze, ale i MySQL asi bude lepší než Postgres. Třeba za pár let bude možné použít Oriole storage engine https://www.orioledata.com/.
V roce 2016 migroval Uber z Postgresu na MySQL - a možná hlavním důvodem byly problémy při write heavy provozu https://www.uber.com/en-CZ/blog/postgres-to-mysql-migration/
Vždy to chce vyzkoušet - záleží na počtu indexů, velikosti tabulek, velikosti RAM, rychlosti IO, ... nicméně pokud děláte opravdu hodně UPDATE a zvlášť na menší množině řádků, tak je potřeba hodně VACUUM a na to se mohou nabalovat další problémy. Jinak pro zajímavost - na Postgresu běží s přehledem a velkou rezervou Aukro, relativně bez problémů Fortuna, atd atd.
-
Logik, nemas ty nejaku "cognitive dissonance"? Lebo pises na jednej stranke aka je mysql dobra a rychla a vykonna a ako pgsql mozno uz ma vsetky ficury a mozno uz nie je taka pomala a potom na druhej strane hovoris ze pgsql all the way. To nedava moc zmysel :)
Ked sa bavime o kontexte vypnutej db na zalohy, co uz sme poriesili, ze tam nie je rozdiel teda. A ked chcem pokracovat v konverzacii pre a proti, tak som este nepocul nejaky solidny argument pre pgsql teda, okrem emocionalnych a subjektivnych pohladov(co je v poriadku, kazdy ma pravo mat rad co ma rad, niekt oma rad apple, iny ms, niekto samsung, iny ios, niekto mysql, iny pgsql...).
Nehovorim ze treba pokracovat v diskusii, kedze hlavna otazka bola zodpovedana. Ale ak ma niekto nieco k pgsql vs mysql tak kludne sem s tym.
-
Ehm, imho to vidíš příliš složitě. Dobrá databáze s rozumnou architekturou ...
Jenze se bavime o myslq ...
Jinak ve finale zalezi predevsim na tom, co si muzes dovolit a co ses ochoten pripadne zaplatit.
Muzu se na to podivat klidne nasledovne. Eshop. Co se muze podelat? Vlastne hromada veci se muze podelat zcela mimo moji kontrolu - uprostred nejakyho procesu lehne zakaznikovi net, a nenadelam s tim nic ...
Takze se k tomu muzu postavit klidne i tak, ze si reknu, OK, vetsina databazi prezije i odpojeni natvrdo, holt ztratim nejaky data. Ty muzu ztratit i milionem jinych zpusobu. Takze proste budu delat snapy za jizdy bez dalsiho, coz je vlastne presne totez jako kdyz to natvrdo vypnu, a budu doufat, ze aspon jedna z tech 3,5 10 ... zaloh bude fukcni a proste odepisu data za posledni hodinu, den, tyden ...
A muze to byt naprosto relevaltni a zcela koser pristup, proste pro me ty data nemaji takovou hodnotu, abych to nejak uber resil, predpokladam, ze pokud nekomu objednavka nedorazi, objedna si to pak znova.
Jenze tenhle pristup samozrejme je tim problematictejsi, cim rozsahlejsi je cela infrastruktura, protoze to samozrejme nasledne ovlivni hromadu dalsich systemu.
-
jjrsk: ale v tvojom priklade akosy absentuje existencia transakcii ktore su prave na toto robene.
-
petersveter:
sorry, ale co je nepochopitelného na tom, že
- MySQL má v určitých specifických workloadech větší výkon (viz Pavel Stěhule)
- set featur MySQL není podmnožinou setu featur PostgreSQL
- ale že 99% (a spíš ještě o pár devítek více) vývojářů se s implementací, kde by to, že PostgreSQL je v daném workloadu nedostatečně výkonná, nebo že neimplementuje danou featuru, nikdy v reálu nepotká (např. já si myslím, že už jsem nějaké i poměrně komplexní systémy dělal, a k limitům Postgresky jsme se nepřiblížili asi nikdy). Takže sice je dobré o tom vědět, ale to nic nemění na tom, že je rozumný přístup prostě používat Postgres, a MySQL uvažovat jako možné řešení jen v (čistě teoretickém) případě, že narazíš na limity Postgres (což nenarazíš) - s tím, že většinou pak stejně je rozumější to udělat jinak (např. nasadit Redis nebo něco podobného a do SQL jen agregovat).
jjrsk:
- No já jsem čistě polemizoval s Tvým "databáze musí umět" v kontextu toho, co jsme řešili. Tam jsi psal nejen o MySQL, ale i o "normální databázi" :-)
- Jinak ano, může to být možný přístup. Ale vzhledem k tomu, že každá záloha má smysl, jen když je nějak natrénováno obnovení, takže na rozumné implementaci záloh tak jako tak spálíš nějaký čas, tak už zas nevidím důvod, proč nepoužít např. ty WAL logy a neztratit, pokud je to možné, nic.
Nastavit to zálohování dle manuálu na pokusném stroji není zas tak "hardcore", aby se to nedalo, a zkrátí to podstatně dobu obnovy (nemusíš hledat snapshot, který "se povedl", máš přesně definovaný postup obnovy). Samozřejmě to jsme zas u toho, že když máš MySQL, tak to (asi?) nejde - ale to je přesně důvod, proč doporučuju PostgreSQL: místo vymejšlení partizánskejch postupů, jak obejít nestandardnosti MySQL my přijde rozumnější nevymejšlet kolo, ale udělat to tak, jak se má, s nástrojem, který je na to vhodný. Ve výsledku člověk ušetří nervy i čas.
-
vetsina databazi prezije i odpojeni natvrdo, holt ztratim nejaky data
Databáze splňující ACID se používají právě proto, že ani při odpojení natvrdo nepřijdete o žádná data z potvrzených transakcí. To je to D v ACID – Durability. Samozřejmě pokud databázi nepodtrhnete nohy nějakým úložištěm, které bude tvrdit, že data jsou uložená, ale nebude to pravda. Pokud vám ACID databáze po tvrdém odpojení napájení (nebo jiném výpadku) ztrácí data z potvrzených transakcí, máte něco ošklivě rozbité. (Což samozřejmě neznamená, že nemůžete o data přijít jiným způsobem – pokud je výpadek napájení způsoben zkratem kvůli stoupající vodě, asi vám moc nepomůže pocit, že těsně před tím, než se disk utopil, byly na něm zapsané všechny potvrzené transakce.)
-
Logik, nemas ty nejaku "cognitive dissonance"? Lebo pises na jednej stranke aka je mysql dobra a rychla a vykonna a ako pgsql mozno uz ma vsetky ficury a mozno uz nie je taka pomala a potom na druhej strane hovoris ze pgsql all the way. To nedava moc zmysel :)
PostgreSQL je opensource databáze, která je podobná „velkým“ databázím jako MS SQL nebo Oracle, mnohdy je i dokáže nahradit. Obvykle se PostgreSQL chová tak, jak by člověk od slušné relační databáze čekal. Pokud někdo zvažuje, s jakou opensource relační databází začít, zvolil bych jednoznačně PostgreSQL.
MySQL/MariaDB jako jednoduchá databáze, která fungovala v podstatě jako souborová databáze, ale byl to server a komunikovalo se s ním pomocí SQL (přičemž to spoustu částí SQL příkazů ignorovalo). Postupně se přidávaly další enginy a MySQL/MariaDB se přibližuje „dospělým“ databázím – ale pro bezpečné použití pořád potřebujete vědět, co umí a co neumí, jaká jsou omezení. V některých specifických případech může mít MySQL/MariaDB lepší výkon, než PostgreSQL (prakticky než kterákoli „velká“ databáze). MySQL/MariaDB bych tedy použil jedině v případě, kdy jsem si vědom jejích omezení a mám důvod ji použít, protože mám specifickou zátěž, pro kterou je MySQL lepší. Reálně je častý důvod, proč se použije MySQL/MariaDB to, že je to jediná databáze, kterou nějaký PHP hosting nabízí…