MariaDb - ako zalohovat/obnovovat db?

[petersveter]

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.

[Reklama]

[Kit]

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é.

[redustin]

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.

[R.S.]

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.

[petersveter]

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 ?

[Reklama]

[_Tomáš_]

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.

[petersveter]

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.

[_Tomáš_]

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í.

[petersveter]

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.

[_Tomáš_]

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ě.

[petersveter]

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?

[jjrsk]

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.

[Filip Jirsák]

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).

[petersveter]

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.

[_Tomáš_]

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.