Názory k článku
Udržujte si svou databázi v bezpečí s Pgpool2

Zdravim, velmi pekny clanok, doporucujem pre prehladnost opravit obrazok, nakolko v texte serveri oznacujete ako PG1,2,3 ale na obrazku su vsetky oznacene ako PG1.

iSCSI, GusterFS, DRBD…

Co se týče databází, tak pokud mám 2 servery, stačí myslím master-master replication, kde není potřeba „load balanceru“. Nevím jestli to umí PG, ale MySQL od verze 5 ano. Master-Master má navíc tu výhodu (oproti master-slave), že si hlídají autoincrementy, takže v tom pak nevzniká nepořádek.

Add „ztráta spojení při výpadku jednoho serveru“ uvedená v článku. Je to logické. Prostě je potřeba zrušené spojení vytvořit jinam. Tomu se lze vyvarovat pokud „jeden server rozložíte na 2 stroje“. Tam již samozřejmě loadbalancer potřebujete, ale výpadek jednoho neukončí uživatelovu session.

Ty autoincrementy myslite, ze jedna db ma sude a druha liche? pripadne v konfiguraku nastavit „step“ pro kruhovou replikaci? Nebo nejaky jiny figl. Zkousel jsem Master-Master i kruhovou replikaci a chodilo to krasne s malym poctem dotazu, dokud jsem to nedal do provozu – pod velkou zatezi cca 400updates/sec se to zaclo cele rozbijet, takze jsem porad nucen jet mysql master – multislaves :(

Způsob je popsán tu: http://dev.mysql.com/…-master.html

Já se zmiňoval jen o 2 strojích, jako je to zde v článku. Při více strojích se již samozřejmě uplatňuje kruhová replikace.

Neznám sice Váš konkrétní případ, ale v takovém případě nevím jestli nemá cenu se poohlížet po něčem co tohle zvládne bez problémů (např. Real application cluster či podobné řešení).

Velmi jednoducho sa to cita, ale prax je bohuzial uplne ina. Master<->master je nepouzitelne (resp. nezarucuje konzistentnost dat=pruser), ak nie je k dispozicii synchronna replikacia. DRBD sice zarucuju synchronnu replikaciu, ale co na to mysql proces, beziaci na druhom masterovi (je to hot/cold backup?) , ked sa mu pod rukami menia data na disku ? Resp. co ak su zosynchronizovane data z pohladu mysql po pade aktivneho mastra v nekorektnom tvare (pochopitelne zelezitost storage engine) ? Mozno som to nepochopil , ale naco vlastne master/master, ak je tu pokus o zdielanie dat (pracuju nad spolocnym FS?) ? Mozno treba pockat na integraciu „google patchov“. Toto vsetko mi zatial pripada taky zlepenec.

Je to tak jak píšete… Já to nechtěl zas tolik rozebírat.

DRBD, iSCSI a GlusterFS jsem myslel pouze jako společné úložiště pro statická data (společné soubory). Nikoliv pro databázi. Příště se pokusím přesněji se vyjadřovat.:-)

A co se stane kdyz dojde k vypadku PG3? Neni tady Single point of failure?

Vypadne to celé, samozřejmě. Pokud by dělal někdo High-Availability v praxi, tak minimálně se 2 load balancery.

Samozrejme se jedna o Singl Point. Mozne reseni najdes v mem komentari nize. Na obranu autora je nutno dodat ze tohle je typicka testovaci (pokusna) konfigurace a o ni v tomto clanku predevsim slo. Nikdo pricetny kde chce tvrdit, ze ma tuto sluzbu v HA samozrejme tuto konfiguraci ciste tak jak je nepouzije, ale nejak zajisti HA nad middlewarem pgpool aby odstranil Singl Point.

a INSERT posílá na všechny zúčastněné.

Znamena to, ze tydle „replikace“ jsou zalozene na posilani stringu s SQL prikazama? Pokud ano, tak vysledkem urcite neni replika, ale jen dve podobne databaze… Co se stane pokud v INSERTu je nejake now() apod.?

Replikacni reseni vetsinou pracuji na trosku vice low-level urovni (coz znamena jejich integraci do enginu dane DB)

Spousta databází nabízí více způsobů replikace. Třeba Informix má jednak synchronní replikaci HDR, která je „v enginu“, protože pracuje na „fyzické“ úrovni (synchronní přenos diskových stránek), a jednak replikaci ER, která pracuje na „logické úrovni“ (asynchronní přenos datových řádků), a jestli se nepletu, je to řešeno pomocí triggerů. V replikačních řešeních pro PostgreSQL se nevyznám, ale myslím, že tak by to šlo řešit i v PostgreSQL (pomocí post-insert, post-update a post-delete triggerů), takže problém s NOW() a spol. by odpadl.

A máte s tím nějaké praktické zkušenosti? Mně to pořád odrazuje, protože to používá triggery. Tedy neumí to replikovat změny schématu, je to náchylné na přístupová práva, replikační vrstva „sedí přímo v databázi“ a používá to triggery, které mi může někdo smazat, apod… Zkrátka si nedovedu představit, že to nasadím pro nějakého zákazníka s tím, že „každou změnu ve schématu musíte dělat na obou serverech, potom musít spustit XY, který obnoví trigerry, jo a ty trigerry nesmíte nikdy smazat a musíte jim dát ke všemu přístup…“

Co se týče pgpoolu, pak jediný problém bude s NOW(), který se vyřeší synchronizací času (to je samozřejmost) a zjištěním, zda bude vadit, když se hodnota při nějaké obnově změní. Jinak sekvence a autoinkrementy jsou zlo, na tomhle příkladu je alespoň vidět proč :-)

A existuje i možnost, kdy se server nastaví tak, aby dělal WriteAheadLogy na nějaké sdílené místo a druhý server běžel v konstantím režimu obnovy a rovnou WAL logy zpracovával. http://www.postgresql.org/…standby.html

Zkus nasadit Slony pod nejakou dynamicky se rozvyjejici aplikaci u ktere se neustale meni datove schema s radove alespon stovkama tabulek a velmi brzy zjistis, ze je to v podstate neudrzitelne reseni. Ale je take jedno z moznych. Slabina tohoto reseni prave pro tyto druhy aplikaci je prave v to, ze Slony je Trigger-based. Ale tim netvrdim ze pod jinymi aplikacemi nemuze davat vyborne vysledky.

Jeste dodatkem kratky seznam reseni ktera jsem uz potkal pro zajisteni replikace (a dalsich veci) pro postgreSQL:

Warm Stand By Kopírování a aplikace WAL. – zatim pro me nespolehlive

SLONY-I Trigger-based master-slave replikace. – testoval jsem, prijde mi narocne na udrzbu

Londist Trigger-based master-slave replikace.

Squoia Middleware-based multi-master replikace. – velmi nadejna architektura

Pg-Pool II Middleware-based multi-master replikace. – muj osobni vitez :-)

HA-JDBC Client-driver-based multi-master replikace.

Postgres R Certification-based multi-master replikace.

GCluster Multi-master replikace.

Bucardo Master-master replikace.

Mammoth PostgreSQL Replicator Log-based master-slave replikace. – testoval jsem dava velmi dobre vysledky pro odpovidajici aplikaci a formu dat.

Tungsten Replikator Heterogeneous log-based master-slave replikace. – velice nadejne ale jeste nejsou naimplementovany agenti pro PostgreSQL

Tohle řešení je dost pochybné a doufám, že existuje i něco lepšího. Jak už někdo napsal, pgpool komp se může rozbít – a hlavně, musí se to odstavit na synchronizaci. Já bych asi řešil celou věc jako RAID, kdy by každý počítač s databází měl vlastně připojený disk do pole přes síť (a radši ne AoE, aby to šlo přes internet) a ještě nějak vyřešit přístup k poli ze dvou serverů. Stejně by ale bylo těžké zařídit, aby uživatel nic nepoznal, protože návštěva čehokoli je od začátku navržená jako spojení jednoho s jedním, DNS jsou hodně cacheované, takže přehození adresy serveru pod stejnou doménou nepůjde tak rychle… Zkrátka by to asi dopadlo jako javascript, co by uživatele přesměroval na druhý server, když by se protáhlo spojení.

Ty odkazy na Django a CherryPy ve třetím odstavci jsou skutečně zajímavé ;-DD

Ahojte,

myslim ze toto samotne ma chybu v navrhu… Pgpool umre a je konec :-) Moznosti je mnoho… samotny webserver (apache, mod_proxy_balancer) je skutecne dnes jiz banalitou. Replikace dat (rozumejte stranek) je dobre resit pomoci DRBD a napr. GFS2. Databaze muze byt slozitejsi orisek… ale co jednoduse uzivat vyhod sdileneho diskoveho uloziste, a pri chcipnuti DB na nodu #1 (v R/W) ji zapnout na druhe strane (node #2)? Data precik mate (DRBD, ale samozrejme muze dojit k chybe [chcipne pri provadeni operace, nutny repair] apod…). Ikdyz Master-Master zas tak hrozny neni… Dnes je moznosti vice jak dost :-)

Skumal som, co by som mohol pouzit na replikaciu pqsql databaz, kde mam desiatky az stovky tabuliek s roznymi vazbami, primarnymi klucmi a blobami (oid, nie bytea). Zistil som, ze neexistuje proste nic pouzitelne. Pokial nebude replikacia neoddelitelnou sucastou postgres-u, tak rozne externe nadstavby budu len malou (a malo spolahlivou) utechou.

hmm, stejne jako vzdy, clanek nejakeho studentika, ktery si ono reseni precetl „vcera vecer“ na nejakem anglickem webu a prepatlal to do cestiny, procetl par veci okolo, aby se ujistil, ze to nejsou takove bludy.

Ptam se rovnou, kolik stovek/tisic techto reseni mate nekde nasazene? funguje to vubec, zkousel jste to alespon jednou nebo jste to sproste nekde opsal? Kolik jinych HA reseni jste kdy mel moznost resit, mate alespon nejake znalosti z teto problematiky(skolu, skoleni/certi­fikaty? praxi)?

Stale vice se zde projevuje → kdo neumi ten uci.

do redakce: Nemohla by takova clanky publikovat sikovnejsi anglictinarka se zakladni znalosti linuxu a dovednosti dohledavat si veci z googlu? Mozna by se tak cena za honorar dalsi snizim o 1/2, 1/3 … kdo vi.

Angličtinářka asi ne, protože to by se honorář musel spíš naopak několikrát zvýšit :-)

Vasich rodicu je mi lito …

Poohlizel jsem se po databazich se schopnosti synchr.replikace uz pred rokem a jestlize si pridate dalsi podminky – stabilni knihovny rozhrani, dostupne c++ headers a linux, nemate prakticky co nasadit…

Zkoumali jsme Oracle – pekne nastroje pro vyvoj, nadherna databaze, clustery, ale kdyz prislo na OCI resp. OCCI, dostavate slabe misto, ktere neni jak obejit – problemy s ABI kompatibilitou, nekdy vam prozmenu spadne aplikace na tom, ze databaze jednou za cas vyhodi hlasku pro zmenu hesla a OCI nepodporuje kod vyslany databazi..

Kdyz prislo na postgresql, skoncili jsme to po dvou dnech ve stavu, kdy replikace resena pomoci pgpool prestavala byt stabilni a narusila se konzistence obou databazi.

Nakonec to tedy vyhralo technologicky nejslabsi reseni – mysql. Kod sice obsahuje neopravene bugy stare 4–5let, syntaxe ulozeneho SQL je oproti Oracle archaicka, ulozene procedury jsou podporovany prakticky jen od verze 5, navic existuje pouze jediny pouzitelny nastroj pro vyvoj a debugovani, jenze jakmile prijde rec na propojeni se systemem a moznosti clusteru, tak jako jedina nabizi potrebnou stabilitu.

Zajimal by me vas nazor…

Neckermann se pro svuj webshop (v predvanocnich nakupnich orgiich 3500 hits/sec) take rozhodl pro mysql cluster. Financne i vykonove spicka. Je treba ovsem rici, ze na implementaci se podilela mysql sama s nekolika vyvojari, kteri realizovali jakasi vylepseni, ktere nejsou v beznem kodu.

Rad bych se zeptal, co si mam predstvit pod: ‚syntaxe ulozeneho SQL je oproti Oracle archaicka‘

Podivejte se na MySQL 5.4. Mela by se daleko lepe chovat na viceprocesorovych systemech. Odstranili take nejaka uzka hrdla pri praci s filesystemem. Obecne by mel jit vykon na slusnem HW hodne nahoru. De facto vyvojari z MySQL zapracovali do produkcni db google patche a nejake patche od Percony. Bohuzel se stabilitou verze 5.1 natoz 5.4 je to zatim tak spatne (spousta, pro me pomerne fatalnich bugu, jako necekane prepnuti transakcniho modu read commited na repeatable read apod.), ze bych to do produkce zatim nenasazoval.

Kdyz jsem cast systemu vyvijel puvodne v Oracle, zvyknul jsem si na pohodli. To pohodli vychazelo jednak ze syntaxe (to je ciste subjektivni zalezitost – musim rici, ze mi PL/SQL vyhovovalo vice nez podpora ANSI/ISO standardu od mysql), druhy duvod byl pragmatictejsi a tykal se podpory spravy chyb a vyjimek v mysql. Oproti moznostem Oracle je mysql 5.1 stredoveka sudlice, v 5.4 jsou jiz sice pridany signaly (uprimne zatim jsem nemel cas procist k tomu vice), ale presto mi prijde zpusob zapisu nepohodlny. Jestlize chcete primo v databazove ulozene logice vytvorit komplexni vrstvu a nejsou k dispozici funkce zjistujici napr. kod posledni chyby nebo jeji textovy popis, stava se debugovani takoveho systemu spis slepeckou alchymii (mate moznost vytvorit handlery na konkretni kody chyb, ale vzdy je potreba zajistit ohlidani celeho zbyleho stavoveho prostoru a tam uz neni k dispozici prostredek pro blizsi identifikaci selhani). Vse je samozrejme mozne kombinovat s prostredky identifikace chyb v databazovem rozhrani aplikace (pouzivam mysql++), to uz ale neni ciste reseni dusledky nekdy boli..

Presne tak, jak ja bych rad pouzival PostgreSQL, kdyby umela replikaci tak jednoduse a stabilne jako MySQL. Ty 4 roky stare bugy napriklad ve zpracovani subselectu me na MySQL taky toci. Replikaci v PostgreSQL slibuji od verze 8.4 jako jeji soucast. To by mohlo Postgresu hodne pomoct. Z MySQL mam posledni dobu dost rozporuplne pocity, i kdyz vykonove na zakladni nekomplexni dotazy nema konkurenci a replikaci rozbeha i laik behem par minut.

Diky za info o PostgreSQL 8.4. Dival jsem se do dokumentace a mela by poskytnout zajimave moznosti. Skoda, ze se jedna teprve o RC2. V pripade databaze bych se neodvazil nasadit ostrou verzi, ktera neni starsi nez rok :( Nezbyva nez cekat :)

„Když se podíváte na dnešní servery, tak obsahují věci jako dva zdroje, RAID 1, ECC paměti, UPS, diesel agregáty a některé třeba umí zahodit za běhu samotný procesor.“

Ja chci diesel do serveru, kde to prodavaji?

Pekny clanek. Pgpool2 prave testuji a pripravuji se ho nasadit do produkcniho prostredi. Mam ho v konfiguraci replikace + loadbalancing a funguje zatim bezchybne.

Pouzivam reseni kdy mam dva stroje a na kazdem mam jednu databazi a zaroven i jeden pgpool, konfigurace do krize. Pro pgpool jsem ufunkcnil init skripty pro Linux-HA. Pgpool2 mi zajisti HA nad postgresem a Linux-HA, se kterym jsem to testoval, a nebo RHCS (Red Heat Cluster Suite), ktery mame jiz nasazeny v provozu a ktery se pro produkcni nasazeni jevi pricetneji, mi zajisti HA nad middlewarem pgpool2. Pokud obalime pgpool init skripty, tak to je v podstate jen dalsi sluzba nad kterou muzeme vytvorit HA dle nasi libosti. Pri takoveto konfiguraci muzeme jeden server rozmlatit sekerou a databaze bude dale dostupna. Samozrejme se tato konfigurace nemusi omezovat pouze na dva nody, ale muze jich byt takto zapojeno N pri stale stejne konfiguraci.

Velmi se mi v konfiguraci zamlouva moznost konfigurovat loadbalance koeficienty u jednotlivych serveru, jimz vyresime situaci kdy nemame uplne stejne vykonne zelezo.

Jako nejvetsi slabinu monetalne vidim proces obnovy po ztrate nodu (funguje, ale ocekaval bych, ze to pgpool bude uz resit sam a ne ja svymi skripty :-) ).