2026. október 12. · 1 perc olvasás

A PostGIS magas rendelkezésre állása több, mint replikáció

A replika még nem átkapcsolási terv. Mi kell valójában egy olyan térbeli adatbázishoz, amelynek működnie kell.

A cikk tartalma
  1. A replikáció a kezdet
  2. Az automatikus átkapcsoláshoz bíró kell
  3. Mentések, amelyeket tényleg visszaállítottak
  4. A térképréteg is számít
  5. Frissítések és tesztek
  6. Először a számokat döntse el

A második adatbázis-szerver az, ahol a legtöbben kezdik. De nem itt ér véget a magas rendelkezésre állás.

A replikáció a kezdet

A PostgreSQL streaming replikáció egy másik szerveren tartja a PostGIS adatbázis másolatát. Ez egy lemezhibától megvéd. Önmagában viszont nem kapcsolja át az alkalmazásokat a másolatra, ha az elsődleges szerver meghal, és nem véd egy elrontott DELETE-től sem, mert a hiba is replikálódik.

Az automatikus átkapcsoláshoz bíró kell

Valakinek el kell döntenie, hogy az elsődleges szerver tényleg elveszett, elő kell léptetnie pontosan egy replikát, és erről értesítenie kell a többieket. Rosszul csinálva két elsődleges szerver fogad írást, ez a „split brain”, ami sokkal rosszabb a leállásnál. Az olyan eszközök, mint a Patroni, ezt elosztott konszenzus-tárral (etcd) és három szavazó taggal oldják meg, így hálózati szakadás nem hozhat létre két vezetőt. Az alkalmazások terheléselosztón vagy virtuális IP-n át csatlakoznak, amely mindig az aktuális elsődlegesre mutat.

Mentések, amelyeket tényleg visszaállítottak

A replikáció és a mentés más problémát old meg. Kell az időpontra pontos helyreállítás folyamatos WAL archiválással (általában pgBackRestet használunk), egy telephelyen kívüli másolat, és ütemezett visszaállítási próbák. Az a mentés, amit még soha nem állítottak vissza, remény, nem mentés.

A térképréteg is számít

A felhasználók nem az adatbázist látják, hanem a térképet. Több állapotmentes GeoServer vagy MapProxy példányt futtatunk terheléselosztó mögött, csempéket gyorsítótárazunk, és gondoskodunk róla, hogy egy lassú lekérdezés ne vigye el az egész szolgáltatást.

Frissítések és tesztek

A leállások többsége tervezett. A másolaton begyakorolt, gördülő frissítések ezt nullához közelire csökkentik. Élesítés előtt pedig szándékosan elrontunk dolgokat: leállítjuk az elsődlegest, megszakítjuk a hálózatot, megtöltünk egy lemezt, és nézzük, mi történik.

Először a számokat döntse el

Mennyi adatot veszíthet el (RPO), és mennyi ideig lehet leállva (RTO)? A válaszok döntik el az architektúrát és az árát, ezért még az eszközök kiválasztása előtt meg kell egyezni rájuk.

Kritikus térinformatikai rendszert tervez?

Meséljen a rendszeréről. Az első konzultáció ingyenes.