Podešavanje PostgreSQL replikacije na Linuxu: Rešenje visoke dostupnosti

Article Image

Zašto replikacija PostgreSQL-a na Linuxu povećava dostupnost vaših servisa

Ako upravljate aplikacijom koja ne sme da prekida rad, replikacija baze podataka je ključna komponenta visokodostupne arhitekture. Replikacijom postižete da se promena na glavnom (primary) čvoru automatski preslika na jedan ili više rezervnih (standby) čvorova; u slučaju kvara primarnog čvora, rezervni može preuzeti bez gubitka podataka ili sa minimalnim zastojevima. Na Linux platformi imate stabilno okruženje za implementaciju replikacije zahvaljujući dobroj mrežnoj podršci, upravljanju servisima i alatima za automatizaciju.

Uprkos prednostima, replikacija donosi dodatnu kompleksnost: morate planirati sinhronizaciju WAL logova, mrežne rute za failover, sigurnosne postavke i procedure za testiranje. U nastavku ćete razumeti osnovne pojmove i konkretne pripremne korake koje treba preduzeti pre same konfiguracije.

Ključni pojmovi replikacije koje treba poznavati

Modeli replikacije

  • Asinkrona replikacija: Primary potvrđuje transakciju pre nego što standby primi promenu — veći throughput, manja latencija za klijente, ali postoji rizik od gubitka poslednjih zapisa ako primary otkaže.
  • Sinhrona replikacija: Primary čeka potvrdu od jednog ili više standby čvorova pre nego što potvrdi transakciju — minimalan gubitak podataka, ali veća latencija.
  • Logical vs Physical: Fizikalna (streaming) replikacija prenosi WAL segmente i obezbeđuje identičan diskovni sadržaj; logička replikacija omogućava selektivno repliciranje tabela i promena.

Komponente koje pratite

  • WAL (Write-Ahead Logging) — osnovni mehanizam za prenos promena.
  • Primary/Standby uloge — ko prihvata upise, ko replicira čita.
  • Failover i switchover procedure — automatizovane (Pacemaker, Patroni) ili ručne.

Priprema Linux okruženja: šta treba proveriti pre konfiguracije

Pre nego što počnete sa konfiguracijom PostgreSQL replikacije, proverite sledeće aspekte sistema kako biste izbegli poznate probleme i nepotrebno zastoje:

Sistemske i mrežne provere

  • Verzija PostgreSQL-a: preporučuje se ista verzija i patch level na primary i standby čvorovima.
  • Vreme i sinhronizacija satova: osigurajte NTP/chrony sinhronizaciju da biste izbegli probleme sa vremenskim žigovima WAL zapisa.
  • Firewall i portovi: otvorite TCP port 5432 (ili prilagođeni) između čvorova; omogućite pristup za replikacionog korisnika.

Postavljanje korisnika i dozvola

  • Napravite replikacionog korisnika u PostgreSQL-u sa privilegijom REPLICATION.
  • Prilagodite pg_hba.conf da dozvoli replikaciju sa odgovarajućih IP adresa/segmenta mreže.
  • Proverite dozvole na nivou OS-a za direktorijume podataka i backup skripte.

Kada završite ove pripreme, bićete spremni za konkretnu konfiguraciju postgresql.conf, inicijalnu sinhronizaciju podataka i test failovera — sledeći deo vodiča sadržaće korak‑po‑korak uputstva za te radnje.

Konfiguracija postgresql.conf za streaming replikaciju

Glavne opcije u postgresql.conf koje morate podesiti na primary čvoru direktno utiču na ponašanje replikacije. Minimalni skup preporučenih parametara za fizičku (streaming) replikaciju izgleda ovako:

  • wal_level = replica (ili logical ako koristite logičku replikaciju) — obezbeđuje dovoljno informacija u WAL‑u za standby čvorove.
  • max_wal_senders = 5 — broj procesa koji mogu slati WAL stream; prilagodite broju standby čvorova.
  • wal_keep_size = 512MB (ili veća vrednost) — koliko WAL segmenata zadržavate lokalno da biste smanjili rizik da standby zakaže zbog nedostupnih segmenata.
  • archive_mode = on i archive_command = 'cp %p /var/lib/pgsql/wal_archive/%f' — opciono, za WAL shipping i PITR (backup + WAL arhiva).
  • hot_standby = on na standby mašinama — omogućava čitanje podataka na replica instanci.

Za sinhronu replikaciju podesite i:

  • synchronous_commit = on (na primary ili na nivou transakcije).
  • synchronous_standby_names = '1 (standby1, standby2)' — određuje koji standby čvorovi moraju potvrditi promenу da bi primary potvrdio transakciju.

Nakon izmene restartujte ili reloadujte servis (systemctl restart postgresql ili pg_ctl reload) i proverite logove za greške. Takođe podesite pg_hba.conf da dozvoli CONNECT/REPLICATION za odgovarajućeg replikacionog korisnika sa IP adresa standby čvorova.

Inicijalna sinhronizacija podataka: pg_basebackup i WAL shipping

Pre nego što standby može da počne da aplicira WAL zapise, mora imati konzistentnu kopiju data direktorijuma. Najjednostavniji način je pg_basebackup:

  • Na standby mašini pokrenite: pg_basebackup -h primary.example.com -D /var/lib/pgsql/12/data -U replicator -X stream -P -R. Opcija -X stream obezbeđuje da potrebni WAL segmenti budu uključeni, a -R automatski generiše konfiguraciju za povezivanje sa primary (u modernim verzijama kreira standby.signal i postavlja primary_conninfo).
  • Ako ne koristite pg_basebackup, možete napraviti konzistentan fizički snapshot preko filesystem snapshot‑a ili rsync, ali obavezno snimite trenutni WAL i postavite odgovarajuće recovery parametre.

Dodatna strategija je WAL shipping: omogućite archive_mode = on i navedite archive_command koji kopira WAL u deljeno skladište. Standby može preuzimati WAL fajlove iz arhive (korisno u kombinaciji sa streamingom kao fallback).

Pre nego što završite, kreirajte fizičku replikacionu slot na primary da sprečite prethodno uklanjanje WAL segmenata:

SELECT * FROM pg_create_physical_replication_slot('slot_name');

Budite oprezni: slotovi drže WAL i mogu brzo zauzeti disk — monitorišite veličinu.

Provera replikacije i procedure za failover/promociju

Posle inicijalne sinhronizacije, verifikujte stanje replikacije sledećim koracima:

  • Na primary proverite pg_stat_replication za spisak standby veza i metrike kao što su write_lag, flush_lag, replay_lag.
  • Na standby koristite SELECT pg_is_in_recovery(); i SELECT pg_last_wal_replay_lsn(); da potvrdite da primate i primenjujete WAL zapise.
  • Za numeričko praćenje zakašnjenja, izračunajte razliku LSN-ova koristeći pg_wal_lsn_diff(pg_current_wal_lsn(), pg_last_wal_replay_lsn()).

U slučaju failover-a, standby možete promovisati komandama kao što su pg_ctl promote ili SELECT pg_promote();. Nakon promocije, bivši primary može biti rekonfigurisан kao new standby — najbolje pomoću pg_rewind (ako je disk pristupačan i vremenska linija nije previše divergentna) ili ponovnim basebackup-om. Testirajte ove korake u kontrolisanim uslovima pre produkcije da biste izbegli zastoje i gubitak podataka.

Automatizacija i alati za upravljanje replikacijom

Za produkcijska okruženja često je poželjno koristiti alate koji pojednostavljuju failover, nadzor i rekonfiguraciju klastera. Popularne opcije uključuju:

  • Patroni — upravljanje HA klasterom sa distribuisanim konsenzusom (etcd/consul) i automatskom promocijom.
  • repmgr — alat za upravljanje replikacijom i failover procedurama, koristan za upravljanje topologijom i skriptovane switchovere.
  • Pacemaker + Corosync — sistem za orkestraciju resursa na nivou čvorova, pogodan za kompleksnije HA zahteve.

Uvijek testirajte integraciju tih alata u kontrolisanim uslovima i planirajte rollback scenarije. Pored toga, uvestе monitoring (Prometheus + pg_exporter, Zabbix, ili slični) i alerting da biste brzo detektovali latenciju replikacije, rast korišćenja diska zbog replication slot-ova i probleme sa arhiviranjem WAL fajlova.

Kratke operativne preporuke pre i posle promene u produkciji

  • Redovno testirajte failover i recovery procedure na staging okruženju.
  • Pratite veličinu WAL arhive i replication slot-ova da ne biste došli u situaciju da disk postane pun.
  • Automatizujte rutinske zadatke (backup, rotaciju WAL-a, proveru integriteta) i čuvajte istoriju promena konfiguracije.
  • Ograničite mrežni pristup replikacionom interfejsu i koristite šifrovanje (SSL/TLS) za primenu podataka između čvorova kada je to moguće.

Završne napomene

Postavljanje i održavanje replikacije zahteva planiranje, redovno testiranje i disciplinu u operacijama — ali benefit u pogledu dostupnosti i otpornosti sistema čine napor isplativim. Uvijek imajte jasne procedure za promociju i povratak (failover/swıtchback), pratite metrike i upozorenja, i dokumentujte sve promene. Za detaljnije tehničke reference i preporuke pogledajte Zvanična dokumentacija PostgreSQL replikacije.