ugrás a tartalomhoz

MySQL vs. PostgreSQL: backup

Bártházi András · 2005. Dec. 30. (P), 17.57
Gerzsonnal a MySQL vs PostgreSQL lehetőségeiről beszélgettünk, de egy olyan topicban, ami eredetileg másról szól. Ennek kapcsán gondoltam, hogy kezdjünk neki egy topicnak, és hasonlítsuk össze a kettőt. A célja a dolognak részemről az lenne, hogy egy kicsit jobban megismerhessem a PostgreSQL lehetőségeit, ennek kapcsán szívesen vennék felvetéseket is a PostgreSQL-t használók részéről is (miben jobb, milyen érdekes dolgok vannak benne, amit nem lehet MySQL-lel megcsinálni, stb.). Főként az egyszerűbb nyelvi feladatokat kívánó, vagy az architektúrát tárgyaló kérdéseket érdemes megvitatni, mivel a PostgreSQL nyelvi szinten egyértelműen többet nyújt.

Amire elsőként kiváncsi lennék mint adatbázis adminisztrátor, hogy hogyan lehet hatékonyan backupot csinálni PostgreSQL-lel? A sima pg_dump-ot azért nem gondolom az igazinak, mert vagy nem lesz konzisztens a backup, vagy pedig LOCK-olni kell a táblákat, ami egy látogatott honlapnál, vagy kihasznált szervernél nem biztos az igazi.

MySQL-nél két megoldást tudok. Az egyik LOCK-kal jár ugyan, de bináris másolat készítését engedi meg. A MyISAM táblatípus adatbázisonként külön könyvtárban, táblánként külön fájlban tárolja az adatokat, így ha írás ellen LOCK-olom a menteni kívánt adatbázist, fájl szinten tudok bizonsági másolatot készíteni (sokkal kisebb helyet foglal mint egy dump, illetve sokkal gyorsabb is). A bináris másolat általában többé-kevésbé verzió és platformfüggetlen (jó tapasztalataim vannak).

A másik megoldás egy kicsit advancedebb, de nem egy bonyolult prodcedúra ez sem: a lényeg, hogy két adatbázisszerver kell hozzá üzemeltetni (akár ugyanazon a gépen, akár egy másik gépen), és beállítani, hogy a mentendő adatbázis replikációs szerverként viselkedjen. A replikáció lényege, hogy minden utasítás, ami a MASTER-en megváltoztatja az adatbázist, a SLAVE-en, a mentést biztosító szerveren is végrehajtódik. Ez a terheléselosztáson kívül jól jöhet biztonsági másolatra is: gyakorlatilag van egy mindig aktuális másolat az éles adatbázisról. A SLAVE tetszőleges időre leállítható, így tudok egy snapshotot csinálni róla, majd mikor újraindítom, akkor gyorsan beéri a MASTER-t.

Ezekről itt lehet olvasni: http://dev.mysql.com/doc/refman/5.0/en/disaster-prevention.html

Milyen lehetőséget vannak PostgreSQL-nél? Mi az, amiben többet tud kínálni esetleg számomra? Ezt a részt találtam a doksiban: http://www.postgresql.org/docs/8.1/interactive/backup.html, itt használható módszerként csak a pg_dump használatát említi, vagy egy teljes adatbázis leállítás és teljes mentés lehetőségét (ami azért elég sokáig is eltarthat).
 
1

PostgreSQL backup lehetőségek

Hodicska Gergely · 2005. Dec. 31. (Szo), 15.19
A MySQL esetén vázolt módszerek mind léteznek PostgreSQL esetében is, plusz egyéb lehetőségek is vannak.

A sima pg_dump-ot azért nem gondolom az igazinak, mert vagy nem lesz konzisztens a backup, vagy pedig LOCK-olni kell a táblákat, ami egy látogatott honlapnál, vagy kihasznált szervernél nem biztos az igazi.

Nem kell ilyesmitől félni. Az MVCC-nek (multiversion concurrency control) köszönhetően nincs szükség semmilyen lockolásra, a pg_dump képes konzisztens mentést készíteni úgy, hogy közben az adatbázis teljes mértékben használható. Ezekívül tudsz vele egy saját formátumot is generálni, aminek az előnye, hogy a pg_restore paranccsal tetszőleges objektumokat tudsz vele visszaállítani.

sokkal kisebb helyet foglal mint egy dump

Hát ez sok esetben nem így van. Az elmásolt cucc tartalmazni fogja az összes indexet például, ami a dumpban nem lesz benne. Meg ha ne minden egyes sor külön insertként van a dumpban (ami teljesítmény szempontjából is ajánlott), akkor relatíve kevés "haszontalan" adat van a dumpban.

A bináris másolat általában többé-kevésbé verzió és platformfüggetlen (jó tapasztalataim vannak).

Erre nem alapoznám a mentés használhatóságát. Elég könnyen változhat a tárolási formátum egy verzió váltás során. Persze ha tuti nem szeretnéd másik verzió alatt használni, akkor jó lehet, de pl. pont mostanság elég gyakran jönnek ki MySQL-ből is az új verziók.

A másik megoldás egy kicsit advancedebb, de nem egy bonyolult prodcedúra ez sem: a lényeg, hogy két adatbázisszerver kell hozzá üzemeltetni (akár ugyanazon a gépen, akár egy másik gépen), és beállítani, hogy a mentendő adatbázis replikációs szerverként viselkedjen.

Mentés szempontjából nézve (figyelmen kívül hagyva az egyéb előnyöket, amiket írtál) ez eléggé kerülő megoldás. Ezért használni egy másik adatbázist elég költséges mulatság, és mindezt csak azért mert nincs erre egy használható megoldás.
Amúgy replikációt a Slony-val tudsz megvalósítani PostgreSQL esetében, legalábbis ez a legelterjedtebb eszköz erre. Ez szintén aszinkron, egy irányú replikációt tesz lehetővé, de finombban konfigurálható, illetve kaszkádosítható. Itt nem salve/master van, hanem node-ok vannak, amik két félék lehetnek: subscriber vagy origin. Itt seteket lehet replikálni, amik táblák és szekvenciák tetszőleges csoportját jelenti. Setenként állítható, hogy egy adott node az ő szemszögéből origin vagy subscriber.

Tisztán backup célokra viszont egy kifinomult megoldást nyújt a PITR (point-in-time recovery) technológia. A PostgreSQL minden változást a WAL (write-ahead logging) logokba először. A módszer lényege, hogy készítünk egy teljes mentést az adatbázisról egy adott pillanatban, majd ezeket a logokat folyamatosan archíváljuk (erre van támogatás). Ha bármikor gond van, akkor a teljes mentést visszaállítjuk, majd "lejátszuk" ezeket a logokat, így az adatbázis a "gond" beli (vagy ahhoz nagyon közeli) állapotára állítható vissza. Ezenkívül így lehetőségünk van arra is, hogy a teljes mentést egy másik gépre is feltesszük, majd a logokat folyamatosan itt is lejátszuk, ezáltal egyfajta replikáció valósítható meg.


Felhő
2

Cool

Bártházi András · 2005. Dec. 31. (Szo), 19.26
Pont ilyen társalgásra gondoltam. :)

A sima pg_dump-ot azért nem gondolom az igazinak, mert vagy nem lesz konzisztens a backup, vagy pedig LOCK-olni kell a táblákat, ami egy látogatott honlapnál, vagy kihasznált szervernél nem biztos az igazi.

Nem kell ilyesmitől félni. Az MVCC-nek (multiversion concurrency control) köszönhetően nincs szükség semmilyen lockolásra, a pg_dump képes konzisztens mentést készíteni úgy, hogy közben az adatbázis teljes mértékben használható. Ezekívül tudsz vele egy saját formátumot is generálni, aminek az előnye, hogy a pg_restore paranccsal tetszőleges objektumokat tudsz vele visszaállítani.


Ez valóban jól hangzik.

sokkal kisebb helyet foglal mint egy dump

Hát ez sok esetben nem így van. Az elmásolt cucc tartalmazni fogja az összes indexet például, ami a dumpban nem lesz benne. Meg ha ne minden egyes sor külön insertként van a dumpban (ami teljesítmény szempontjából is ajánlott), akkor relatíve kevés "haszontalan" adat van a dumpban.


Hogy az indexet is le kell-e másolni, nem vagyok biztos benne, azt könnyen le lehet generálni megint. De lényegében egyetértünk. Ami tuti: a bináris készítése és visszaállítása sokkal gyorsabb.

A bináris másolat általában többé-kevésbé verzió és platformfüggetlen (jó tapasztalataim vannak).

Erre nem alapoznám a mentés használhatóságát. Elég könnyen változhat a tárolási formátum egy verzió váltás során. Persze ha tuti nem szeretnéd másik verzió alatt használni, akkor jó lehet, de pl. pont mostanság elég gyakran jönnek ki MySQL-ből is az új verziók.


Én alapozom rá. Ugyanolyan verziók esetén nyilván nincsen gond a visszaállítással, tehát a mentés mint mentés biztosan működik. Az egyes MySQL verziók között a tárolási formátum minimálisan változik. Sőt, nem változik. Itt főként a MyISAM táblákkal vannak tapasztalataim, sok olyan tábla van még jelenleg is meg nekem MySQL 5.0 alatt, ami még a 3.23-as verzióban lett létrehozva, s azóta nem nyúlt hozzá senki, nem konvertáltam sohasem, csak bináris másolás történt. Windows alatt már rég nem futtattam MySQL-t, de anno a tapasztalat az az volt, hogy a tárolási mód (MyISAM táblák) platformfüggetlen (miért is ne lenne az?).

A másik megoldás egy kicsit advancedebb, de nem egy bonyolult prodcedúra ez sem: a lényeg, hogy két adatbázisszerver kell hozzá üzemeltetni (akár ugyanazon a gépen, akár egy másik gépen), és beállítani, hogy a mentendő adatbázis replikációs szerverként viselkedjen.

Mentés szempontjából nézve (figyelmen kívül hagyva az egyéb előnyöket, amiket írtál) ez eléggé kerülő megoldás. Ezért használni egy másik adatbázist elég költséges mulatság, és mindezt csak azért mert nincs erre egy használható megoldás.
Amúgy replikációt a Slony-val tudsz megvalósítani PostgreSQL esetében, legalábbis ez a legelterjedtebb eszköz erre. Ez szintén aszinkron, egy irányú replikációt tesz lehetővé, de finombban konfigurálható, illetve kaszkádosítható. Itt nem salve/master van, hanem node-ok vannak, amik két félék lehetnek: subscriber vagy origin. Itt seteket lehet replikálni, amik táblák és szekvenciák tetszőleges csoportját jelenti. Setenként állítható, hogy egy adott node az ő szemszögéből origin vagy subscriber.

Tisztán backup célokra viszont egy kifinomult megoldást nyújt a PITR (point-in-time recovery) technológia. A PostgreSQL minden változást a WAL (write-ahead logging) logokba először. A módszer lényege, hogy készítünk egy teljes mentést az adatbázisról egy adott pillanatban, majd ezeket a logokat folyamatosan archíváljuk (erre van támogatás). Ha bármikor gond van, akkor a teljes mentést visszaállítjuk, majd "lejátszuk" ezeket a logokat, így az adatbázis a "gond" beli (vagy ahhoz nagyon közeli) állapotára állítható vissza. Ezenkívül így lehetőségünk van arra is, hogy a teljes mentést egy másik gépre is feltesszük, majd a logokat folyamatosan itt is lejátszuk, ezáltal egyfajta replikáció valósítható meg.


Azért nem tartom kerülő megoldásnak a replikáció készítését, mivel pont a valódi backupot valósítja meg: ha meghal az éles szerver, bármikor ott az éppen legújabb, működő másolat. Nyilván nem állítok be még egy MySQL-t ugyanazon a gépen, hiszen annak baromira nincsen semmi értelme.

A replikáció konfigurálásáról: a MySQL esetében sincsen akadálya a konfigurálhatóságnak, egy szerver lehet egyszerre MASTER és SLAVE is. Ami megkötés, hogy egy szervernek csak egy MASTER-je lehet.

MySQL esetén is van "point-in-time recovery" és "write-ahead logging", itt bináris lognak hívják. Ez a replikációhoz megy is szépen.

-boogie-
4

BUÉK

Hodicska Gergely · 2006. Jan. 1. (V), 10.06
Úgy tűnik nem tudok olyan kocka lenni, hogy én legyek idén az első hozzászóló. Anonymous kolléga megelőzőtt :).

Hogy az indexet is le kell-e másolni, nem vagyok biztos benne, azt könnyen le lehet generálni megint.

Úgy értettem, hogy ha simán a könyvtárat elmásolod, akkor abban az indexek is benne lesznek.

Én alapozom rá. Ugyanolyan verziók esetén nyilván nincsen gond a visszaállítással, tehát a mentés mint mentés biztosan működik. Az egyes MySQL verziók között a tárolási formátum minimálisan változik. Sőt, nem változik.

Oké, csak ezt senki sem garantálja neked.

Itt főként a MyISAM táblákkal vannak tapasztalataim.

Mondjuk ez a tábla típus jóformán nem tud semmit, belefér, hogy ne változzon a formátuma. Könnyen lehet, hogy egy InnoDB esetén már nem ez lenne a helyzet, főleg az új verziók esetén.

Azért nem tartom kerülő megoldásnak a replikáció készítését, mivel pont a valódi backupot valósítja meg: ha meghal az éles szerver, bármikor ott az éppen legújabb, működő másolat.

Ez azért nézőpont kérdése. Jelen esetben neked jelent valami pluszt ez a meleg tartalék módszer. De ha erre nem lenne szükség, akkor is kénytelen lennél még egy DB-t futtatni, míg PostgreSQL alatt erre nincs szükség.

A replikáció konfigurálásáról: a MySQL esetében sincsen akadálya a konfigurálhatóságnak, egy szerver lehet egyszerre MASTER és SLAVE is. Ami megkötés, hogy egy szervernek csak egy MASTER-je lehet.

OKé, csak PostgreSQL esetén tábla sziten lehet állítani, hogy mi szinkronizálódjon.

MySQL esetén is van "point-in-time recovery" és "write-ahead logging", itt bináris lognak hívják.

Ez erős túlzás. Kb. azt lehet mondani, hogy van bináris log, és kész. PostgreSQL esetében a WAL log eléggé más szerepet tölt be, mint MySQL esetében. Ez utóbbinál kb. "van", ha kérjük, míg előbbinél a tranzakció kezelés alapja, mindig generálódik. Illetve MySQL esetében nincs PITR, nem tudsz egy adott időpont beli állapotba visszamenni.


Felhő.elmentem.aludni
3

click next

gerzson · 2005. Dec. 31. (Szo), 22.09
Tovább nyomtam a PostgreSQL dokumentációjaban a következő oldalra. Nem vagyok naprakész ebben a témában, de ahogy átolvastam az oldalt nekem érthetőnek tűnt, h. mit kell tenni: base backup + WAL archiving, és máris kész a leállítás nélküli, online backup.

ui.: az általad írt pg linknek a végére került egy vessző (404).
testing can reveal the presence of errors, but never their absence. - Edsger Dijkstra