fsync
Nastavením způsobu synchronizace datových souborů jsme se zabývali již v minulém dílu u parametru wal_sync_method a výběru správného způsobu synchronizace s ohledem na bezpečnost dat na disku. Nastavení fsync=off synchronizaci dat na disk vypíná zcela. Toto nastavení sice zrychlí práci databáze (ukládání dat na disk) na možné maximum (databázový server se nebude vůbec starat o bezpečné zapsání dat na disk), ale také významně ohrozí data při pádu serveru (výpadek elektrické energie, chyba hardwaru a také i chyba softwarová). Při běžném použití PostgreSQL je proto nutné vždy nechat synchronizaci zapnutou (nastavení fsync=on).
Existují ale výjimečné situace, kdy je možné synchronizaci zcela vypnout. Jsou to případy, kdy je potřeba velmi rychle nahrát již existující data do databáze (například obnovení ze zálohy). V takovém případě k ohrožení dat nedojde, protože i při případném výpadku databáze jsou data stále k dispozici. Po nahrání dat je ovšem nutné (pro další provoz) synchronizaci opět zapnout.
Dalším speciálním případem, kdy je možné synchronizaci vypnout, jsou slave servery (například pro účely náročnějších dotazů, které by zbytečně dlouhodobě zaměstnávaly master server), kdy jsou data replikována z masteru. Opět, data jsou k dispozici a pokud dojde k jejich ztrátě na slave serveru, lze je získat opět z mastera.
Tak či onak, je důležité vědět, že toto nastavení přímo ovlivňuje bezpečí dat a při vypnuté synchronizaci a následném výpadku (z různých důvodů), téměř jistě dojde k neopravitelnému poškození datových souborů. Na druhou stranu existují situace, kdy je takto získaná rychlost přednější a data je (po výpadku) možno opět získat odjinud.
full_page_writes
Také nastavení full_page_writes se přímo týká bezpečnosti dat na disku podobně jako fsync a v běžném provozu je nutné nechat nastavení na výchozím full_page_writes = on. Při vypnutí kompletních zápisů stránky může (při havárii) dojít k poškození souborů WAL logu (a tedy neopravitelnému poškození dat) a dokonce k horšímu, nedetekovatelnému, poškození a k tzv. silent data corruption (data jsou formálně v pořádku, ale hodnoty jsou změněné). Toto poškození dat se velmi složitě odhaluje a může prorůstat do dalších systémů.
max_prepared_transactions
Mnoho lidí (pozn. autora: i mě to prvně v konfiguračním souboru zmátlo) si nastavení max_prepared_transactions dává mylně do souvislosti s technikou připravených příkazů (prepared statement), kdy si lze připravit příkaz a opakovaně jej volat s jinými parametry. Tato volba slouží pro nastavení počtu připravených transakcí pro dvoufázový commit. V drtivě většině běžných nasazení PostgreSQL je možné tuto volbu nechat ve výchozím nastavení.
„Rady“ optimalizátoru dotazů
Je celá řada nastavení týkajících se optimalizátoru prováděcího plánu, které lze navíc volat i v rámci připojení klienta. Někteří programátoři je používají (či spíše zneužívají) jako rady optimalizátoru plánu, který z nějakého důvodu nepoužije optimální způsob vykonání dotazu. K tomuto použití též částečně nahrává fakt, že PostgreSQL v dotazech nepodporuje rady (hints), které mají jiné databázové servery. Občas tak lze v SQL kódu zahlédnout řádky, které tam nepatří, například zde se zakazuje průchod celou tabulkou, použije se průchod pomocí indexu:
set enable_seqscan = off
Obecně je to velmi špatná technika. V nových verzích PostgreSQL se optimalizátor plánu a vykonávání dotazů optimalizuje a tyto nevhodné „nápovědy“ jej pak zbytečně omezují. Pokud optimalizátor z nějakého důvodu nevybere optimální plán, je často možné dotaz přestavět jinak, nastavit větší počet statistických hodnot pro vybrané sloupce apod.
Shrnutí
Výchozí nastavení PostgreSQL serveru je velmi úsporné. Co se týče paměťových nároků, někdy možná až příliš bezpečné, co se ukládání dat týče a v neposlední řadě také příliš tiché, z hlediska informací ukládaných do logů. Administrátor potřebuje především vědět, co se v jeho serveru děje, k čemuž mu slouží záznamy v logách. Server vyžaduje jistou péči a také znalosti o uložených datech. Toto nastavení jsme si ukázali hned na začátku seriálu, v prvním dílu.
Uživatel chce mít svá data rychle k dispozici, ale také v bezpečí. Jak správně v PostgreSQL nastavit rychlý a bezpečný způsob práce s diskem, jsme probrali zejména ve druhém dílu. Databázový server vyžaduje co největší množství paměti, které musí být pečlivě zvoleno a nastaveno k různým účelům. Tím jsme se zabývali ve třetím dílu.
Cílem tohoto seriálu bylo ukázat alespoň některá nastavení a jejich vhodné hodnoty s cílem získat z databázového serveru co nejvyšší výkon a administrátorský komfort.
