Natív PostgreSQL replikáció
Tartalomjegyzék |
1 Bevezetés
A PostgreSQL 9.0-ás verziójától kezdve támogatja a natív replikációt, ami talán ez az egyik legjobban várt funkciója hosszú idők óta. Eddig is léteztek más replikációs megoldások (PgPool II, Slony, stb.), amelyek akár többlet funkcionalitással is rendelkezhettek (load balancing), mégsem jelentenek igazi megoldást a problémáinkra. A jelen szócikk ezen témakörbe nyújt egy kis betekintést.
A replikáció konfigurálásához két debian Linux operációs rendszert használok csomagból telepített PostgreSQL 9.1 verziókkal. Az alaprendszer squeeze, ehhez a szükséges binárisokat a wheezy tárolóiból töltöttem le (csak hozzá kell adni a tárolók a sources.list-hez). A két szerver közvetlenül is össze lesz kötve egymással (172.16.0.0/24-es hálózat), ez a failover szempontjából fontos. Több szerver esetén a közvetlen összeköttetések nagyon megbonyolítanák a beállításokat, akkor célszerűbb switch-eken keresztül összekapcsolni a rendszereket.
2 Követelmények
2.1 Replikáció követelményei
A replikációnak több követelménye van, ami nem csak az PostgreSQL verziószámára terjed ki:
- a replikációban részt vevő operációs rendszereknek azonos architektúrájúnak kell lennie
- legalább PostgreSQL 9.0
Azonos architektúrának számít, ha mind amd64, x386 stb. Látszik hogy nem szabad keverni 32 és 64 bites rendszereket, csak tisztán az egyiket, ill. tisztán a másikat használhatjuk. Törekedni kell a PostgreSQL-t is azonos verzión tartani. Ha frissítjük, célszerű először a slave rendszerrel kezdeni, mert valószínűbb, hogy egy új rendszer képes feldolgozni egy régebbi üzeneteit, mint fordítva.
2.2 Failover követelményei
- közvetlen kapcsolat a két szerver között
- egy virtuális IP cím
A fent ismertetett felállás szerint a két szerver közvetlen kapcsolatban kell álljon egymással. Ez azért jó, mert a kapcsolat csak a két oldaltól függ, vagyis nagyon stabilnak tekinthető. Ha egy switchen keresztül kapcsolódnának egymáshoz, a switch kiesése működésképtelenné tenné a rendszert.
3 A replikáció működése
A PostgreSQL replikáció a WAL (Write Ahead Log) szegmensek átvitelén alapul. A WAL tömören annyi, hogy mielőtt egy tranzakciót érvényesítenénk az adatbazison (pl. egy rekordot beszúrnánk), a tranzakciót leíró WAL szegmenst egy olyan perzisztens tárra írjuk, ami áramkimaradás, rendszerleállás, egyszóval hiba esetén is hibátlanul visszaolvasható. Egy WAL fájl mérete tipikusan 16 Mb, de ettől más értéket is megadhatunk. A perzisztens tárra írás után az adatbázis feldolgozza a WAL fájlokat.
4 Replikáció fajtái
A replikáció fajtáit többféleképp is csoportosíthatjuk. Az egyik szempont lehetne az, hogy egyszerre hány adatbázist tudunk írni a clusterünkben, a másik hogy a replikáció során mennyire vannak szinkronban a szervereink.
4.1 Master - slave
A legegyszerűbb megvalósítás a master - slave alapú felállás. Ekkor a több adatbázisunkból mindig csak egyet írhatunk (master), viszont az olvasások történhetnek a master-ből vagy bármely csak olvasható (slave) adatbázisból. Ha egy load balancing célszoftvert is alkalmazunk, akkor megtehetjük azt, hogy az INSERT és UPDATE műveletek a master-re továbbítódjanak, míg az olvasások megoszlanak a slave-ek között.
4.2 Master - master avagy multi master
A másik felállás szerint az összes adatbázisba írhatunk és az egyes beírt rekordokat az adatbázisok maguk között replikálják. Ez a bonyolultabb eset, a PostgreSQL-ben nem található erre megvalósítás, de egyéb szoftverekkel elérhető (pl. Bucardo).
4.3 Fájl alapú
A fájl alapú replikáció a WAL fájlok átmásolásával érhető el. A master szerver az író/módosító műveletek hatására WAL fájlokat generál, ezeket a fájlokat kell átmásolni a slave szerverekre. Az átmásolást nekünk kell megoldani, erre általában rsync-et használnak. A hátránya, hogy explicit átmásolás nélkül nincs replikáció. Egy cron-ból történő rsync meg tudja oldani a másolást, de ez legalább egy perces késleltetést jelent és nem túl szép.
4.4 Streaming
A streaming replikáció során egy wal_sender nevű process fog elindulni a master szerverünkön, míg a slave-eken egy-egy wal_receiver. A céljuk a WAL szegmensek folyamatos átvitele a master-ről a slave-ekre.
4.5 Aszinkron
Aszinkron replikáció esetén a WAL fájloknak a masteren történő feldolgozása és a slave-ekre történp kiküldése között lehet egy kis késletetés. Ez azt jelenti, hogy egy író/módosító műveletet a master nyugtáz, azt ő végre is hajtotta, de a slave-eken még nem történt meg az írás/módosítás.
4.6 Szinkron
Szinkron replikáció esetén kijelölhetünk egy! (csakis egy) slave szervert, akivel a master szinkron kapcsolatot fog felépíteni. Szinkon kapcsolat alatt azt értem, hogy egy író/olvasó műveletet a master mindaddíg nem igazol vissza, míg azt a szinkron slave társa végre nem hajtotta. Ezis egy késletetést fog a rendszerbe vinni, hiszen a WAL szegmenst át kell másolni, ugyanazt a műveletet két helyen is végre kell hajtani, a szinkron slavenek vissza kell ígazolni és a master csak ezután tudja nyugtázni a tranzakciót. Ha ilyen replikáción gondolkodunk, mindenképp olyan slave-et válasszunk szinkron társnak a master mellé, ami minél gyorsabb és minél kisebb válaszidejű kapcsolaton elérhető. A példánkban egy közvetlen kapcsolat van a két szerver között, ez tökéletesen megfelel a célra. Minimális követelménynek tekinthető, hogy legalább egy LAN-on legyen a két szerver.
4.7 Kaszkádosított
A kaszkádosított replikáció egy kicsit kilóg a sorból abban az értelemben, hogy ez inkább replikációs terheléselosztásnak tekinthető. A PostgreSQL 9.2-es verziójától kezdődően használhatjuk, a segítségével nem kell az összes slave-nek a masterről replikálnia, az mintegy "hullám" végighaladhat a rendszerünkön. Képzeljünk el egy olyan esetet, amikor van van masterünk, mellette egy szinkron slave és az összes többi slave a szinkron slave-ről replikál. Ezzel a mastert jelentősen tehermentesítettük. Érezzük, hogy ez a feature főleg nagy clusterek építésekor hasznos.
5 Streaming szinkron replikáció konfigurálása
Először is fel kell telepítenünk mindkét gépünkön a PostgreSQL-t:
apt-get install postgresql-9.1
