Natív PostgreSQL replikáció
(→Streaming szinkron replikáció konfigurálása) |
(→Streaming szinkron replikáció konfigurálása) |
||
| 90. sor: | 90. sor: | ||
<pre> |
<pre> |
||
host replication replicator 172.16.0.2/32 md5 |
host replication replicator 172.16.0.2/32 md5 |
||
| + | </pre> |
||
| + | A postgresql.conf-ban pedig állítsuk az elábbi sort: |
||
| + | <pre> |
||
| + | hot_standby = off |
||
| + | </pre> |
||
| + | erre: |
||
| + | <pre> |
||
| + | hot_standby = on |
||
</pre> |
</pre> |
||
A lap 2012. december 3., 23:07-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. 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
Ez a parancs feltelepíti a szükséges függőségeket is, a konfigurációs állományokat a /etc/postgresql/9.1/main alá helyezi. A legfontosabb konfig fájl a postgresql.conf és a pg_hba.conf. Az előbbiben állíthatjuk be az postgresql paramétereit, az utóbbiban pedig a hozzáféréseket szabályozhatjuk a szolgáltatott adatbázisokhoz. Mindkét állományra szükségünk lesz a továbbiakban. Először is a master és a slave szerveren is állítsuk be, hogy a megfelelő IP címeken figyeljenek. Ehhez módosítsuk a postgresql.conf fájl ezen sorát
#listen_addresses = 'localhost' # what IP address(es) to listen on;
erre:
listen_addresses = 'localhost, 172.16.0.1' # what IP address(es) to listen on;
(természetesen az IP címeket az adott gépnek megfelelően kell behelyettesíteni.) A replikáció lebonyolítására szükségünk van egy felhasználóra, akinek a nevében ez folyni fog. Megtehetjük, hogy a beépített postgres usert használjuk, de ha törekszünk az épp elegendő szintű jogosultságok kiosztására (Principle of least privileges), akkor létre kell hoznunk egy új usert. Ehhez váltsunk át a postgres felhasználóra, indítsunk egy psql shellt és hozzuk létre a usert:
su - postgres psql CREATE ROLE replicator WITH REPLICATION ENCRYPTED PASSWORD 'vasbeton';
Ezzel a megoldással a replikáló userünknek pont annyi joga lesz, mint amire szüksége van. Egy user (role) létrehozásakor a pg_hba.conf fájlban fel kell vennünk egy rekordot, hogy milyen paraméterek mellett engedélyezzük a bejelentkezését. Adjuk hozzá tehát a masteren a pg_hba_conf állományhoz az alábbi sort:
host replication replicator 172.16.0.2/32 md5
Ez azt jelenti, hogy a replication adatbázishoz a replicator (ezt mi hoztuk létre) user a 172.16.0.2-es IP címről csatlakozhat, a jelszavát pedig md5 hashelve küldi el titkosítatlanul (közvetlen összeköttettésünk van, nem kell az SSL, egyéb esetben szükséges lenne). Most állítsuk be a masteren, hogy tudjon a hot standby párjáról. Ehhez szerkesszük a postgresql.conf fájlt:
wal_level = hot_standby # engedélyezi a read-only lekérdezéseket a host standby rendszeren max_wal_senders = 5 # egyszerre max. ennyi standby szerver kapcsolódhat a masterre wal_keep_segments = 16 # ennyi WAL szegmenst fog megőrizni a master a pg_xlog könyvtárban. Erre azért van szükség, hogy az online backup és a streaming replikáció megkezdése között nehogy törölje a master ezeket a fájlokat. A WAL szegmensek általában 16 MB méretűek.
Ezután indítsuk el a masteren a portgrest és készítsünk róla egy backupot, amit átmásolunk a slave-re:
su - postgres
psql -c "SELECT pg_start_backup('label', true)"
exit
cd /var/lib/postgresql/9.1/main
rsync -ave ssh /var/lib/postgresql/9.1/main/ 172.16.0.2:/var/lib/postgresql/9.1/main --exclude backup_label --exclude postmaster.opts --exclude server.crt --exclude server.key --exclude PG_VERSION --exclude postmaster.pid
su - postgres
psql -c "SELECT pg_stop_backup()"
exit
Most térjünk vissza a slave szerverhez. A ph_hba.conf-hoz adjuk hozzá az alábbi sort:
host replication replicator 172.16.0.2/32 md5
A postgresql.conf-ban pedig állítsuk az elábbi sort:
hot_standby = off
erre:
hot_standby = on
