Postgresql 9.1 cluster lehetőségei [felejtős]

Fórumok

Az volna a kérdésem, hogy van-e valakinek tapasztalata postgresql cluster telepítésben, üzemeltetésben?

Azon gondolkodom, hogy jó volna a zabbix szerverem adatbázisán valamilyen fajta terheléselosztást megvalósítani.
Egyrészt tanulási célból, másrészt némileg hibatűrőbb és gyorsabb működés érdekében.
Teljesen kezdő vagyok a témában, de azért megpróbáltam utánajárni hogy milyen lehetőségek vannak.

Valaki írta hogy a postgresql 9.1-nek már van beépített cluster lehetősége.
A kérdés az hogy milyen?
Standby-t és hideg tartalékot nem szeretnék, mert semmit sem gyorsítana a jelenlegi rendszeren.

Nekem ha jól értem, akkor egy multi-master replikációra volna szükségem, ami ugye lehet szinkron vagy aszinkron.
A szinkronnál azt olvastam hogy a két szerver művelet esetén megvárja,
amíg mindkét adatbázison végrehajtásra kerül az aktuális változtatás, és csak utána lép tovább.

Azt is olvastam erről a módszerről, hogy lassabb írást eredményez mint ha egyetlen master szerverem lenne önmagában.
Ez így elsőre már nem jól indul, ezért kezdtem kacsingatni az aszinkron megoldás felé.
Valahol azt láttam hogy ez a postgresql alapértelmezett üzemmódja.
Viszont azt is láttam, hogy egy másik perl fejlesztéssel kiegészítve használják amit "Bucardo" nak hívnak.
Tehát a postgresql 9.1 alapból nem tudja a multi-master aszinkron replikációt, csak ezzel a fejlesztéssel kiegészítve?

Tehát az aszinkron módnál nem várja meg egymást a két szerver.
Gondolom ebben az esetben a még át nem szinkronizált változások elveszhetnének egy esetleges winchesterhiba esetén.

Ami még nem tiszta, hogy a master-slave szerverek esetén van-e bármilyen terhelésmegosztás?
A slave szerver csak a háttérben várakozik, és csak a master kiesése esetén lép az első helyre,
vagy adott esetben bizonyos terheltségi szint fölött a slave szerverre átirányítható a forgalom egy része?

Egyébként mennyire jár sok hibával és napi szintű fejvakargatással egy multimaster vagy egy master-slave adatbázis üzemeltetése?
Régóta mozgatja a terheléselosztás a fantáziám, de azt még nem tudom, hogy érdemes-e rá időt fordítanom.

Előre is köszönöm a válaszokat!

Hozzászólások

9.2-vel kezdjél, mert 9.1-ről a 9.2 átállás munkás.
Az a Zabbix meg Q sok hostot és paramétert monitorozhat, ha cluster kell alá.

9.0: Async. Binary Replication
9.1: Synchronous Replication
9.2: Cascading Replication

igen, érdekel a téma és szeretnék újat tanulni
egyébként 60-70 millió soros tábláim vannak, nem olyan kicsi az adatbázis, de ez még nem indokolja a clustert
amikor 500 hoszt egyenként 28 lekérdezését íratom ki egy összefoglaló táblázatban, akkor azért kicsit gondolkodik mire megjelennek az adatok :)

Vagy a megbízhatóságot növeled, vagy a sebességet.
Illetve lehet a kettőt együtt is, de az nem fog menni két szerverrel.
Master-slave esetén nincs terhelésmegosztás. A kaszkád szinkronizáció gyakorlatilag egy asszinkron master-multislave, azaz gyors, de nem adatbiztos. Annyit tud, hogy nem csak egy slave szerver van, hanem akármennyi lehet, egymás után felfűzve is. Három szerverrel így néz ki:
Master -> upstream -> downstream
Hogy a káoszt fokozzam: http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection…
http://www.postgresql.org/docs/devel/static/different-replication-solut…

köszi! bár bevallom, nem lettem okosabb :)

azt írtad, hogy master-slave esetén nincs terhelésmegosztás
tehát a slave gondolom egy állandóan frissített standby szerver...
majd azt írtad, hogy a master-multislave gyors de nem biztonságos
ezt azért nem tudom értelmezni, mert ha a master és a slave között nincs terhelésmegosztás, akkor gondolom a slave csak a háttérben várakozik
ebben az esetben nem is értem, hogy mi értelme van annak ha több slave is van, másrészt nem értem hogy mi okozza a gyorsulást, ha a master szolgál ki mindenkit

vagy ebben az esetben a slave szerverek végzik a kiszolgálást, és minden slave szerver a masterről szinkronizál?

Zoli78 válaszolt lentebb. A rendszer úgy tud egyszerre LB és HA lenni, ha úgy állítod be a frontendet, hogy a slave-ről olvasol és a masterre írsz.
Az egyik súlyos probléma ezzel az, hogy ez _asszinkron_. Tehát nincs garantálva, hogy ugyanazt az adatot olvasod vissza, amit kiírtál egy másodperccel azelőtt. Komoly rendszerben ez megengedhetetlen. Egy zabbixnak mondjuk jó lehet.
A kaszkád két dologra jó. Egyrészt földrajzi távolságokat jobban át lehet vele hidalni, pl. master: Budapest, upstream: Bécs, downstream: New York. Másrészt a downstream szerver személyében van plusz egy on-line adatbázis mentésed, ami ráadásul nem szegény mastert szlopálja, hanem az upstreamet.

A Postgres alapból azt tudja, hogy a WAL-t (Write Ahead Logot) átküldi a slave-nek. A 9.2-ben a slave-ek egymás után fűzhetőek, így nem a master szervert terhelik a további slave-ek, hanem egy kaszkádos frissítés zajlik a szerverek között. Multi mastert nem tud (az azért elég összetett dolgokat igényelne). Mi pár éve próbálkoztunk a témával és arra jutottunk, hogy a multi master kb. felejtős hacsak nem gondolkodsz drága és fizetős cuccokban. Egy pontig olcsóbb erősebb szervert, gyorsabb háttértárat belepakolni, vagy egyszerűen csak optimalizálni az alkalmazást.
A Postgresszel azt tudod csinálni, hogy az olvasási műveleteket (ami jellemzően a 90-95%-a szokott lenni a lekérdezéseknek) a slave-(ek)re küldöd és csak az írási műveleteket irányítod a masterre. Persze ehhez át kell írni az alkalmazásodat vagy alkalmazni egy olyan db frontendet, ami ezt elvégzi helyetted.