PostgreSQL

Adatbázis: SQL, XML DB

Sziasztok!

Van egy PostgreSQL 9.5-ös verziót futtató RHEL szerverünk egy darab 400 GB adatbázissal. Szeretnénk valami replikációs megoldást bevezetni. Az internet tele van leírásokkal, de minket gyakorlati tapasztalatok érdekelnek inkább.

Amiben gondolkodunk:
Szinkron streaming replikáció repmgr-rel és pgBouncer-rel. Ezek a szempontok:
Szinkronba legyenek az adatok, mert a slave különböző reportokhoz kelleni fog.
Elég egy slave
Zero downtime a beállítás, illetve a replikálás alatt

Főleg az utolsó pont a lényeg. Valakinek van ezzel tapasztalata?

  • 2989 megtekintés

( tompos v | 2016. 02. 17., sze – 13:12 )

Zero downtime mihez? Hogy replikalva legyenek az adatok? Vagy hogy beallitsd? Javaslom, fogalmazz kerek egesz mondatokban:)

A streaming replikáció űködőképes, de ezt a zéró downtime dolgot kissé nem ártana körbejárni.
Mondjuk hogy tudsz 400GB adatot replikálni úgy, hogy közben nicsen tranzakció a masteren?

Ilyen master multislave replikációt sikerrel abszolváltunk pár éve, de ott nulláról indult az adatbázis. (Restore a masterre az alap dumpból, ezzel meg a streaming átvitte az adatokat a slave node-okra). Bizonyára szinkronba lehet hozni valahogy a slave node-okat futó master esetében is,
de ezt mindenképpen tesztkörnyezetben meg kéne tapogatni.

Álmoskönyvek szerint nem kimondottan célravezető egy ilyen "semi HA" adatbázis konfigurációját piszkálgatni élesben.
Ha meg DB restart kell, akkor bármi (egyébként korrigálható) gebasz esetén is kicsúszol a max 1-2 perc downtime ablakból ...

Most jósokat segítettem, ugye ... ? :D
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Ja és az lemaradt, hogy az egészre azért volt szükség, mert nagyságrendekkel nagyobb volt a lekérdezési igény, mint az adat insert.
Ezért kellettek readonly slave-ek, hogy főként a reportingot megtámogassuk.
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Nalunk ez (a kulonbseg atvitele ami ugye elegge hasznalatfuggo) ugy 20-30 perc ketszer ekkora DB merettel ejszakai uzemben (leallitan meg ugye nem kell mert streaming slave osszerakhato futo master mellett is), es nem azert mert lassu a disk vagy a net, hanem azert mert az rsync sajnos 1 szalu es erosen proci limites lesz az atvitel.

Készítettünk már replikációt így, és igaz, ott csak 150 giga körül volt, és valóban, SSD volt alatta, meg sok növekmény se volt, de hamar átment.

Valamint, ugye ne felejtsük el, ha elindítod a pg_start_backup-ot, akkor a fájlrendszeren konzisztens lesz a cucc, de közbe írás, olvasás minden megy. Így nem zavarja az éles használatot a másolás.

Itt most szerintem is te nem értetted, mit akart jelezni tompos. Maga a diff az kicsi lesz valóban, de ahhoz hogy azt a diffet 400g-ból összeszedje az rsync, ahhoz végig kell nyálaznia mind a 400G-át. Az meg nem biztos hogy 20sec lesz. Erősen io függő, tehát hogy mi van alatta.

--
http://pyftpadmin.earthquake.hu

Igy van, senki nem akar attolni 400G/20s sebesseggel:)

Nekem az a tapasztalatom, hogy egyaltalan atnezze a helyzetet az rsync, ahhoz tobb idore van szuksege.
De bevallom, egy ideje mar nem rsync-ezem olyan masszivan. Ha megcsinalja, akkor leborulok elotte. Ennyi volt a mondanom, amire csardij felpattant, mintha a lelkebe gazoltam volna.

Ha nincs sok DML, nincs adatmódosítás, nem sok az XLOG, akkor mehet kis késlekedéssel.
Ha az XLOG-ok sokan vannak és 2-3 standby szerverre nem megy át fizikálisan (IO és net), akkor lesz benne késlekedés.

Célszerű egy standby-t beállítani, arra simán átmegy.

Mennyit nő naponta a 400GB (=mennyi változik benne)?