A logikai replikáció beállítása a PostgreSQL adatbázisban

Az adatbázisok a modern alkalmazások gerincét képezik, és folyamatos elérhetőségük, valamint adatintegritásuk kritikus fontosságú. A PostgreSQL, mint az egyik legnépszerűbb nyílt forráskódú relációs adatbázis-kezelő rendszer, számos funkciót kínál ezen célok elérésére, amelyek közül az egyik legfontosabb a replikáció. A replikáció lényege, hogy az adatokat több szerver között szinkronizáljuk, biztosítva ezzel a magas rendelkezésre állást, a terheléselosztást, az adatok biztonsági mentését, vagy akár az adatmigrációt.

Ebben a cikkben mélyrehatóan tárgyaljuk a logikai replikációt, amely egy rugalmas és nagy teljesítményű megoldás a PostgreSQL-ben. Bemutatjuk, hogy miért érdemes ezt a megközelítést választani, hogyan lehet lépésről lépésre beállítani, milyen előnyei és hátrányai vannak, és mire figyeljünk a működés közben.

Mi is az a logikai replikáció?

A replikáció általánosságban azt jelenti, hogy egy adatbázisról másolatot készítünk, és azt egy vagy több másik szerveren karban tartjuk. A PostgreSQL két fő replikációs módszert kínál: a fizikai és a logikai replikációt.

A fizikai replikáció (más néven streameléses replikáció) a tranzakciós napló (Write-Ahead Log, WAL) blokkszintű másolásán alapul. Ez azt jelenti, hogy a teljes adatbázis-klasztert, beleértve az összes adatot, indexet, táblaterületet és konfigurációt, byte-ról byte-ra másolja a primer szerverről (publisher) a másodlagos szerverre (subscriber). Előnye a nagy sebesség és az adatok teljes konzisztenciája, hátránya viszont, hogy a másodlagos szerver egy pontos mása a primernek, így például nem lehet szelektíven replikálni, vagy különböző PostgreSQL verziókat használni.

Ezzel szemben a logikai replikáció egy rugalmasabb megközelítés. Nem az adatfájlok nyers tartalmát, hanem az adatbázisban végrehajtott egyedi változásokat (INSERT, UPDATE, DELETE műveleteket) replikálja. Ezt a folyamatot a logikai dekódolás (logical decoding) teszi lehetővé, amely a WAL-fájlok tartalmát olvasható, alkalmazható formátumba alakítja. A logikai replikáció a PostgreSQL 10-es verziójában jelent meg beépített funkcióként, és azóta a legmodernebb és legrugalmasabb replikációs megoldásnak számít.

A logikai replikáció főbb alkotóelemei:

Publisher (Kiadó): Az a PostgreSQL szerver, amelyről az adatokat replikáljuk. Itt hozzuk létre a publikációkat.
Publication (Publikáció): Egy definiált csoportja azoknak a tábláknak, amelyeket replikálni szeretnénk. Megadhatjuk, hogy mely DML műveleteket (INSERT, UPDATE, DELETE, TRUNCATE) replikáljuk.
Subscriber (Előfizető): Az a PostgreSQL szerver, amely fogadja a replikált adatokat. Itt hozzuk létre az előfizetéseket.
Subscription (Előfizetés): Egy kapcsolat, amely a kiadó egy adott publikációjára iratkozik fel, és fogadja annak adatait.

Miért érdemes logikai replikációt használni?

A logikai replikáció számos forgatókönyvben ideális választás lehet, ahol a fizikai replikáció korlátai problémát jelentenek:

Szelektív replikáció: Lehetővé teszi, hogy csak bizonyos táblákat vagy táblacsoportokat replikáljunk, nem pedig a teljes adatbázist. Ez különösen hasznos, ha egy másodlagos szerveren csak egy részhalmazra van szükség, például elemzésekhez vagy adatszolgáltatáshoz.
Adatmigráció és verziófrissítés: A logikai replikációval nulla állásidővel migrálhatunk adatokat különböző PostgreSQL verziók között (pl. PostgreSQL 13-ról 16-ra), vagy akár különböző platformokra. Mivel az adatokat logikai szinten értelmezi, a célrendszernek nem kell bit-azonosnak lennie a forrással.
Terheléselosztás és olvasási skálázás: Különböző olvasási terheléseket oszthatunk el a másodlagos szerverek között, miközben a primer szerver csak az írási műveleteket kezeli.
Adatátalakítás (ETL): A replikált adatok egy olvasási replikán érkezhetnek, ahol aztán különféle feldolgozási és átalakítási folyamatokat végezhetünk rajtuk anélkül, hogy a primer szervert terhelnénk.
Homogén és heterogén környezetek: Bár elsősorban PostgreSQL-ről PostgreSQL-re való replikációra tervezték, a logikai dekódolás alapja más rendszerekkel való integrációt is lehetővé tesz (pl. CDC – Change Data Capture) egyedi megoldásokkal.

Előnyök és Hátrányok

Mint minden technológiának, a logikai replikációnak is megvannak a maga erősségei és gyengeségei:

Előnyök:

Rugalmasság és granularitás: Képes táblaszinten szabályozni a replikációt, és akár a DML műveleteket is szűrni.
Verziófüggetlenség: Képes különböző főverziójú PostgreSQL szerverek között replikálni, ami kiválóan alkalmas frissítésekhez és migrációkhoz.
Szelektív replikáció: Csak a szükséges táblákat replikálja, csökkentve ezzel a hálózati forgalmat és a célrendszer terhelését.
Olvasási replikák: Lehetővé teszi dedikált olvasási replikák létrehozását, amelyekre átirányíthatók az olvasási lekérdezések.
Nem blokkoló DDL: A replikáció futása közben lehet DDL (Data Definition Language) műveleteket végrehajtani (bár ezeket manuálisan kell szinkronizálni).

Hátrányok:

DDL műveletek manuális kezelése: A logikai replikáció nem kezeli automatikusan a DDL (pl. ALTER TABLE, CREATE TABLE) műveleteket. Ezeket manuálisan kell elvégezni a subscriber oldalon.
Teljes adatbázis replikáció esetén lassabb: Ha az egész adatbázist replikálni akarjuk, a fizikai replikáció általában gyorsabb és kevésbé erőforrás-igényes.
Szekvencia (SEQUENCE) problémák: A szekvenciák értékei nem replikálódnak automatikusan, ami eltérésekhez vezethet a primer és a replika között. Ezt külön kell kezelni (pl. nagy lépésközű szekvenciák használatával, vagy triggerrel).
Replikációs slot management: A replikációs slotok felügyeletet igényelnek. Ha egy subscriber tartósan elérhetetlenné válik, a hozzá tartozó slot felhalmozhatja a WAL fájlokat, ami lemezterület-problémákhoz vezethet a publisher oldalon.
Nincs automatikus failover: A logikai replikáció önmagában nem biztosít automatikus failover mechanizmust. Ehhez további eszközökre (pl. Patroni, repmgr) van szükség.
Növelt erőforrás-igény: A logikai dekódolás extra CPU és I/O terhelést jelenthet a publisher oldalon.

Előfeltételek és Beállítások

Mielőtt belekezdenénk a beállításba, győződjünk meg róla, hogy a következő előfeltételek teljesülnek:

PostgreSQL verzió:

A beépített logikai replikáció a PostgreSQL 10 vagy újabb verzióiban érhető el. Javasolt a legfrissebb stabil verzió használata.

Publisher oldali konfiguráció (`postgresql.conf`):

A publisher szerveren az alábbi paramétereket kell beállítani a postgresql.conf fájlban:

wal_level = logical: Ez aktiválja a logikai dekódolást, és lehetővé teszi a tranzakciós napló tartalmának logikai formában történő exportálását.
max_replication_slots = N: Adja meg a maximális replikációs slotok számát. N értéke legalább annyi legyen, ahány subscriber kapcsolódni fog (plusz esetlegesen más logikai dekódolást használó bővítmények).
max_wal_senders = N: Adja meg a maximális WAL szálak számát. N értéke legalább annyi legyen, ahány subscriber (és esetlegesen fizikai replika) kapcsolódni fog.
listen_addresses = '*': Engedélyezi a kapcsolódást bármely IP-címről. Szűkíthető konkrét IP-címekre is biztonsági okokból.
port = 5432: A PostgreSQL alapértelmezett portja. Győződjön meg róla, hogy a tűzfal engedélyezi a forgalmat ezen a porton.

Ezek után újra kell indítani a PostgreSQL szolgáltatást a változtatások érvényesítéséhez.

Hálózati hozzáférés (`pg_hba.conf`):

A publisher szerveren a pg_hba.conf fájlban engedélyezni kell a subscriber számára a replikációs kapcsolatot. Példa:

host    replication     rep_user        subscriber_ip/32        md5

Ez a sor engedélyezi a rep_user felhasználónak a replication típusú kapcsolatot a subscriber_ip címről, MD5 jelszóhitelesítéssel. Fontos, hogy a rep_user rendelkezzen a megfelelő jogokkal. Ezen kívül szükség lehet egy sorra az adott adatbázishoz is, ha a subscription copy_data opcióval jön létre:

host    source_db_name  rep_user        subscriber_ip/32        md5

A pg_hba.conf módosítása után újra kell tölteni a konfigurációt (pg_ctl reload vagy sudo systemctl reload postgresql).

Felhasználói jogok:

Hozzunk létre egy dedikált felhasználót a replikációhoz mind a publisher, mind a subscriber oldalon, például rep_user néven. A publisher oldalon a felhasználónak rendelkeznie kell a REPLICATION jogosultsággal (vagy superuser jogokkal). A subscriber oldalon is szükség lehet a REPLICATION jogosultságra, illetve ha az előfizetés az inicializálás során automatikusan másolja az adatokat (copy_data = true), akkor az adott adatbázishoz való hozzáférés is szükséges.

CREATE USER rep_user WITH REPLICATION ENCRYPTED PASSWORD 'your_secure_password';

Lépésről lépésre útmutató a beállításhoz

1. Publisher konfigurálása:

Szerkessze a postgresql.conf és pg_hba.conf fájlokat a fent leírtak szerint. Indítsa újra, majd töltse újra a PostgreSQL-t. Hozza létre a replikációs felhasználót, és hozzon létre egy teszt adatbázist és táblát, ha még nem létezik:

-- Csatlakozás a publisher adatbázishoz (pl. psql -U postgres -d postgres)
CREATE DATABASE source_db;
c source_db
CREATE TABLE employees (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    salary INT
);
INSERT INTO employees (name, salary) VALUES ('John Doe', 50000), ('Jane Smith', 60000);

2. Publikáció létrehozása (Publisher oldalon):

A publikáció definiálja, hogy mely táblákat szeretnénk replikálni, és mely műveleteket (INSERT, UPDATE, DELETE, TRUNCATE). Csatlakozzon ahhoz az adatbázishoz, amelyből replikálni szeretne:

-- Csatlakozás a source_db adatbázishoz
c source_db
CREATE PUBLICATION my_publication FOR TABLE employees;

-- Alternatívák:
-- Minden tábla replikálása az aktuális adatbázisban:
-- CREATE PUBLICATION all_tables_publication FOR ALL TABLES;

-- Csak INSERT és UPDATE műveletek replikálása:
-- CREATE PUBLICATION limited_publication FOR TABLE employees WITH (publish = 'insert, update');

3. Subscriber konfigurálása:

Győződjön meg róla, hogy a subscriber szerveren is fut a PostgreSQL, és elérhető hálózaton keresztül. Hozza létre a céladatbázist és a táblák sémáját (a CREATE TABLE parancsokat), amelyeket replikálni szeretne. Fontos, hogy a táblák szerkezete (oszlopnevek, adattípusok) megegyezzen a publisher oldali táblákéval. Az indexek és korlátok (pl. foreign key) is létrehozhatók előre, de a copy_data opció használatakor a táblának üresnek kell lennie.

-- Csatlakozás a subscriber adatbázishoz (pl. psql -U postgres -d postgres)
CREATE DATABASE target_db;
c target_db
CREATE TABLE employees (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    salary INT
);

4. Előfizetés létrehozása (Subscriber oldalon):

Az előfizetés a publisher egy publikációjára iratkozik fel. Ezt a subscriber szerveren kell létrehozni, azon az adatbázison belül, ahová az adatokat szeretné replikálni. A CONNECTION string tartalmazza a publisher szerver elérhetőségi adatait.

-- Csatlakozás a target_db adatbázishoz
c target_db
CREATE SUBSCRIPTION my_subscription
    CONNECTION 'host=PUBLISHER_IP port=5432 user=rep_user password=your_secure_password dbname=source_db'
    PUBLICATION my_publication
    WITH (copy_data = true, create_slot = true, connect = true);

Fontos opciók:

copy_data = true: Ez az opció inicializálja az előfizetést az összes meglévő adat lemásolásával a publisherről. Ha false, akkor csak az új változások fognak replikálódni.
create_slot = true: Létrehoz egy replikációs slotot a publisher oldalon. Erősen ajánlott, mert ez biztosítja, hogy a publisher ne törölje a WAL fájlokat, mielőtt a subscriber feldolgozná azokat.
connect = true: Automatikusan megpróbál csatlakozni a publisherhez az előfizetés létrehozása után.

Ezek után a logikai replikáció megkezdődik. Az adatok átmásolódnak, majd a további változások valós időben replikálódnak.

Figyelés és Hibaelhárítás

A replikáció megfelelő működésének biztosításához elengedhetetlen a folyamatos figyelés. A PostgreSQL beépített nézeteket és funkciókat kínál ehhez:

Publisher oldalon:

pg_replication_slots: Ellenőrizze a replikációs slotok állapotát. Fontos figyelni a restart_lsn oszlopra, ami azt mutatja, hogy meddig tartja a WAL-t a slot. Ha egy slot inaktívvá válik, és nem törlik, WAL fájlok halmozódhatnak fel.
pg_stat_replication: Ez a nézet a WAL küldők (WAL sender processes) állapotát mutatja, beleértve a replikációs késleltetést (lag) is. A write_lag, flush_lag és replay_lag oszlopok segítenek azonosítani a teljesítményproblémákat.

Subscriber oldalon:

pg_stat_subscription: Ez a nézet az előfizetések állapotáról ad információt, mint például a kapcsolat adatai (subconninfo), az engedélyezési állapot (subenabled), hibaüzenetek (subconnerror) és a feldolgozott LSN (substream_lsn).

Gyakori hibák és megoldások:

„replication slot „…” does not exist” hiba: Ez akkor fordulhat elő, ha a create_slot = true opció nélkül hozták létre az előfizetést, és a publisher időközben törölte a WAL-t. Megoldás: törölje és hozza létre újra az előfizetést a create_slot = true opcióval.
WAL fájlok felhalmozódása a publisheren: Ez általában egy elakadt vagy inaktív replikációs slot miatt van. Ellenőrizze a pg_replication_slots-t, és szükség esetén törölje a felesleges slotokat (SELECT pg_drop_replication_slot('slot_name');).
Adatkonfliktusok: Ha a subscriber oldalon is történnek írási műveletek, vagy ha a publisher DDL változásokat hajtott végre, amelyek nincsenek szinkronban a subscriberrel, adatkonfliktusok léphetnek fel. A logikai replikáció alapértelmezetten leáll, ha ilyen konfliktust észlel. A ALTER SUBSCRIPTION ... SET (disable = true) parancsa segítségével leállítható az előfizetés, majd a konfliktus manuálisan megoldható, mielőtt újraaktiválnánk.
Szekvencia eltérések: Mivel a szekvenciák nem replikálódnak automatikusan, a subscriberen lévő szekvencia értéke elmaradhat. Manuálisan szinkronizálni kell őket (pl. SELECT setval('employees_id_seq', (SELECT max(id) FROM employees));) vagy triggersen keresztül nagy lépésközű szekvenciákat használni.

Gyakorlati tippek és legjobb gyakorlatok

Kezdje kicsiben: Ha még nem ismeri a logikai replikációt, kezdje egy kis tesztadatbázissal és néhány táblával. Így könnyebben megértheti a működését és elháríthatja az esetleges problémákat.
Folyamatos figyelés: Használjon monitoring eszközöket (pl. Prometheus, Grafana) a replikációs késleltetés, a lemezterület és a processzorhasználat figyelésére.
DDL kezelés: Tervezze meg előre a DDL változások kezelését. A legtöbb esetben a DDL-t manuálisan kell alkalmazni a subscriber szerveren, mielőtt a publisheren alkalmazná.
Replikációs felhasználó: Mindig dedikált felhasználót használjon a replikációhoz, minimális szükséges jogosultságokkal.
Tesztelje a katasztrófa-helyreállítást: Rendszeresen tesztelje a helyreállítási folyamatokat, beleértve a subscriber felépítését is egy esetleges primer leállás után.
Ne feledkezzen meg a szekvenciákról: Ha automatikus ID-generálást használ, gondoskodjon a szekvenciák szinkronizálásáról.
Biztonság: Gondosan konfigurálja a pg_hba.conf fájlt, és használjon erős jelszavakat. A kommunikációt SSL/TLS-sel titkosítsa.

Összefoglalás

A PostgreSQL logikai replikáció egy rendkívül erőteljes és rugalmas eszköz a modern adatbázis-architektúrák építéséhez. Lehetővé teszi az adatok szelektív másolását, támogatja a verziófrissítéseket és adatmigrációkat nulla állásidővel, valamint javítja a rendszer rendelkezésre állását és skálázhatóságát.

Bár a beállítása és kezelése igényel némi odafigyelést, különösen a DDL változások és a replikációs slotok tekintetében, az általa nyújtott előnyök (granularitás, verziókompatibilitás, rugalmasság) messze felülmúlják ezeket a kihívásokat. Megfelelő tervezéssel, monitoringgal és karbantartással a logikai replikáció megbízhatóan szolgálja majd alkalmazásait, biztosítva az adatok integritását és elérhetőségét.

Reméljük, hogy ez a részletes útmutató segítséget nyújt a logikai replikáció sikeres beállításában és üzemeltetésében a PostgreSQL adatbázisban. A jövőben a PostgreSQL valószínűleg tovább fejleszti ezt a funkciót, még könnyebbé és automatizáltabbá téve a komplex replikációs feladatokat.