Vlákno názorů k článku Udržujte si svou databázi v bezpečí s Pgpool2 od Richard Marko - za zmienku určite stojí Slony-l, replikacia pre postgres

  • Článek je starý, nové názory již nelze přidávat.
  • 26. 6. 2009 14:52

    Radek Hladik (neregistrovaný)

    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

  • 29. 6. 2009 23:04

    Mips (neregistrovaný)

    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.

  • 29. 6. 2009 23:10

    Mips (neregistrovaný)

    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