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
Szerintem tanulás miatt akarja megcsinálni ahogy en is.
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/
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 :)
RAID-10 sok tengelyen. ;)
Mellesleg a Zabbix server nem cluster ready.
Jelenleg RAID5-öt használunk, és egy SAN storage-ot, de sajnos sok szerver csücsül ezen a storageon.
"Mellesleg a Zabbix server nem cluster ready"
és adatbázis szinten nem lehet clusterezni?
Ha csak nem írod meg.
máris nekiállok :D
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?
A slave-ből csak olvasni tudsz, minden insert/update a masteren történik először, onnan replikál a slave. Ez egy csomó esetben jó megoldás, a te esetedben viszont nem segít.
--
Gábriel Ákos
http://i-logic.hu
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.
köszi a választ!
szerintem marad a zabbix_proxy-s megoldás :)
bár sokat nem segít, de legalább stabilabbak a lekérdezések
helyi lekérdezés esetén nem esik ki annyi csomag (jó esetben semennyi)
bár wifi esetén azért ez nem igaz még helyi lekérdezésnél sem
egyébként használok már proxy-t, de sajnos nem tudtam beállítani hozzá az ügynököt,
így most SNMP-s eszközöket tud csak lekérdezni ill. pingelni tud
Server=ProxyIP-je
Ezt a zabbix_proxy.conf-ban vagy az zabbix_agentd.conf-ban állítsam be?
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.
köszi a hsz-t
reméltem hogy egyszerűbben meg lehet ezt valósítani
ebben az esetben felejtős a téma egyelőre
pgpool-t nézd meg még egyébként.
ok, majd meglesem! :)