Natív PostgreSQL replikáció
(→A replikáció működése) |
|||
| 21. sor: | 21. sor: | ||
== A replikáció működése == |
== 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. |
||
| + | |||
== Replikáció fajtái == |
== 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. |
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. |
||
A lap 2012. november 11., 14:28-kori változata
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. A két szerver közvetlenül is össze lesz kötve egymással, 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).
