Administrace komentářů

KAZDA normalni databaze, pouzivat system log -> data.

Ano, a vrátí potvrzení o provedeném commitu tehdy, pokud jsou data v logu. Tedy na fs, který lze snapshotovat.

A KAZDA normalni databaze UMI dokoncit bezici transakce, zapsat je do dat, a presne v tenhle okamzik az do odvolani ZASTAVI zapis do dat, a zapisuje POUZE do logu.

Ano, a tohle dělá ten zmiňovaný pg_start_backup v případě, že je potřeba kopírovat base soubory, tedy to, co ty nazýváš data, běžnými kopírovacími nástroji.

A PRESNE v tenhle okazik muzes udelat snap.

Nikoliv, snap můžeš pořídit kdykoliv. V tento okamžik je možné použít běžné kopírovací nástroje, protože db je ve stavu, kdy nemění base soubory.

Nekdy bezi databaze v rezimu, kdy se prave presne az do kompletni zalohy uchovava v logu vse, co se udalo od posledni zalohy a pri pripadny obnove lze tudiz ukazat i na zcela konkretni transakci a rict ze se to ma obnovit prave az k ni.

PG umožňuje odlévat wal logy jinam a na základě starší base backup a uchovaných wal logů potom obnovit db k číslu konkrétní transakce. Psal jsem o tom zde, a existují i prográmky, které to nastavení ulehčí (asi jak pro koho), a psal jsem o tom zde. Prosím povšimněte si data vydání článků před tím, než mi budete psát, že existují i mnohem lepší možnosti.

A pokud to presne takhle nedelas, prijdes o data, jak trivilane snadny.

Nepřijdeš, protože db si ukládá wal logy se všemi potvrzenými transakcemi a po např. výpadku proudu vyleje tyhle wal logy do base souborů. Data zůstanou ve stavu poslední potvrzené transakce.

Prijdes o ne v rozahu tech prave bezicich transakci, ktery nejsou kompletne zapsany a tudiz ziskas nekonzistentni databazi, protoze do tech souboru se ty transakce taky nezapisou lusknutim prstu, takze to co se tam prave zapisuje, presne to se pri obnoveni ty databaze (pokud to umi, ne kazda to prezije) zahodi.

Nepřijdeš, protože ta data jsou stále v logu. Z logu zmizí až po té, co jsou base soubory řádně upraveny. Tebou navrhovaný log, který by se mazal ještě před tím, než jsou data zapsána do base souborů, by byl dost k ničemu. Ten log je tam právě od toho, aby se do nej zapisovali změny a ty šly potom zapsat do base souborů.

A ne, ZADNA normalni databaze nepotvrzuje transakci az po zapisu na disk, protoze to, jestli se vubec neco na disk zapsalo ani nemuze vedet, a navic by tim padem byla zcela nepouzitelne pomala.

Každá acid databáze potvrzuje transkaci až po zápisu na disk a právě proto je tak pomalá. wal logy se používají z důvodů, že úprava base souborů je pomalejší, protože jejich struktura je stavěná zejména na rychlé vyhledávání, takže se změny nejdříve logují do linerární sekvence logů, kam stačí jen rychle appendovat a flushnout. Až následně se jejich obsah (který je ale v běžném běhu db v paměti, takže se již nečtou z disku), hromadně vyleje do base souborů. Na tohle ale už klient nemusí čekat.

Stejne tak ti zadnej normalni disk, nepotvrdi to, ze data jsou na plotne, ale pouze to, ze je ma v cache.

Write cache se u disků vypíná. Jinak hrozí rozsypání nejen DB, ale i celého fs. Právě na to, že některé disky vracejí potvrzení zápisu jen po nalití do write cache, se přišlo během vývoje fs typu btrfs nebo zfs. Tyto fs potřebují mít spoleh (zejména v multidevice konfiguraci), že data, která mají být zapsána, skutečně zapsána jsou. Tímto se tedy přišlo na vadný HW.