Autor: [Miłka Teroy](/autorzy/milka-teroy) Analityk rynku hostingowego · Zweryfikowano Kwiecień 2026

1.  [Strona główna](/) ›
2.  [Baza wiedzy](/baza-wiedzy/) ›
3.  PostgreSQL Streaming Replication

# PostgreSQL Streaming Replication — primary i standby

Opublikowano: 10 kwietnia 2026 · Kategoria: VPS i serwery

Backup jest niezbędny, ale nie wystarczy. Gdy serwer PostgreSQL ulega awarii, przywrócenie bazy z pg\_dump może zająć godziny. **Streaming Replication** utrzymuje w trybie gotowości jeden lub kilka serwerów standby, które mają aktualną kopię bazy i mogą w ciągu sekund przejąć rolę primary. Dodatkowo standby może obsługiwać zapytania read-only, odciążając primary. Ten artykuł pokazuje jak skonfigurować replikację fizyczną PostgreSQL 15/16 na dwóch serwerach, uruchomić hot standby i przeprowadzić kontrolowany failover.

## Konfiguracja primary — postgresql.conf i pg\_hba.conf

\# Na PRIMARY: /etc/postgresql/16/main/postgresql.conf

# Wlacz archiwizacje WAL
wal\_level = replica           # replica lub logical
max\_wal\_senders = 5           # liczba rownoleglych polaczen replikacji
wal\_keep\_size = 1GB           # trzymaj WAL do synchronizacji (PostgreSQL 13+)
# Lub uzywaj replication slots zamiast wal\_keep\_size

# Hot standby — pozwala replike obsługiwac SELECTy
hot\_standby = on

# Dla synchronicznej replikacji (opcjonalnie — wolniejsza, ale brak utraty danych)
# synchronous\_standby\_names = 'standby1'
# synchronous\_commit = remote\_apply

# Archiwum WAL (opcjonalne, dla point-in-time recovery)
archive\_mode = on
archive\_command = 'cp %p /var/lib/postgresql/wal\_archive/%f'

# Restart PostgreSQL po zmianach
sudo systemctl restart postgresql

# ----
# Na PRIMARY: /etc/postgresql/16/main/pg\_hba.conf
# Dodaj linię zezwalająca standy na relikację:
# TYPE  DATABASE        USER            ADDRESS                 METHOD
replication   replicator      192.168.1.11/32         scram-sha-256
# (192.168.1.11 = IP serwera standby)

# Utwórz uzytkownika replikacji
sudo -u postgres psql -c "
CREATE USER replicator WITH REPLICATION LOGIN ENCRYPTED PASSWORD 'strong\_repl\_pass';
"

# Przeladuj konfiguracje pg\_hba bez restartu
sudo -u postgres psql -c "SELECT pg\_reload\_conf();"

## Replication slot — gwarancja zachowania WAL

\# Na PRIMARY: stworzenie physical replication slot
sudo -u postgres psql -c "
SELECT pg\_create\_physical\_replication\_slot('standby1\_slot');
"

# Sprawdz dostepne sloty
sudo -u postgres psql -c "SELECT \* FROM pg\_replication\_slots;"
# slot\_name    | active | wal\_status | safe\_wal\_size
# standby1\_slot| f      | reserved   | ...

# Monitorowanie uzytych slotow (pilnuj zeby wal\_status != "lost")
sudo -u postgres psql -c "
SELECT slot\_name, active, restart\_lsn,
       pg\_size\_pretty(pg\_wal\_lsn\_diff(pg\_current\_wal\_lsn(), restart\_lsn)) AS lag
FROM pg\_replication\_slots;
"

# UWAGA: jezeli standby jest offline i slot nie jest uzywany,
# primary bedzie trzymal WAL w nieskonczonosc i moze zapelnic dysk!
# Usun slot jezeli standby jest trwale offline:
# SELECT pg\_drop\_replication\_slot('standby1\_slot');

## Konfiguracja standby — pg\_basebackup i recovery

\# Na STANDBY: instalacja PostgreSQL (ta sama wersja co primary)
sudo apt install postgresql-16 -y
sudo systemctl stop postgresql

# Usuniecie domyslnych danych (zastapione przez pg\_basebackup)
sudo rm -rf /var/lib/postgresql/16/main/\*

# Klonowanie primary przez pg\_basebackup
# -h = host primary, -U = uzytkownik replikacji, -P = progress, -v = verbose
# -R = automatycznie tworzy standby.signal i primary\_conninfo
# -S = uzyj replication slot

sudo -u postgres pg\_basebackup \\
  -h 192.168.1.10 \\
  -U replicator \\
  -D /var/lib/postgresql/16/main \\
  -P -v -R \\
  -S standby1\_slot \\
  --checkpoint=fast

# pg\_basebackup automatycznie stworzyl:
# - standby.signal (plik sygnalizujacy standby mode)
# - postgresql.auto.conf z primary\_conninfo

# Sprawdz wygenerowana konfiguracje
cat /var/lib/postgresql/16/main/postgresql.auto.conf
# primary\_conninfo = 'host=192.168.1.10 port=5432 user=replicator password=... sslmode=prefer'
# primary\_slot\_name = 'standby1\_slot'

# Uruchom standby
sudo systemctl start postgresql

# Sprawdz czy standby sie polaczyl (na standby)
sudo -u postgres psql -c "SELECT pg\_is\_in\_recovery();"  -- powinno zwrocic 't'

# Na PRIMARY: sprawdz polaczone repliki
sudo -u postgres psql -c "SELECT \* FROM pg\_stat\_replication;"

## Monitoring opóźnienia replikacji

\# Na PRIMARY: szczegolowy status replikacji
sudo -u postgres psql -c "
SELECT
  application\_name,
  client\_addr,
  state,
  write\_lag,
  flush\_lag,
  replay\_lag,
  sync\_state
FROM pg\_stat\_replication;
"

# Na STANDBY: ile czasu za primary
sudo -u postgres psql -c "
SELECT
  now() - pg\_last\_xact\_replay\_timestamp() AS replication\_delay,
  pg\_is\_in\_recovery() AS is\_standby,
  pg\_last\_wal\_replay\_lsn() AS last\_replayed\_lsn;
"

# Skrypt monitoringu (mozna uzywac z Nagios/Zabbix)
#!/bin/bash
LAG=$(sudo -u postgres psql -t -c \\
  "SELECT EXTRACT(EPOCH FROM (now() - pg\_last\_xact\_replay\_timestamp()))::int" 2>/dev/null)
THRESHOLD=30  # sekundy

if \[ "$LAG" -gt "$THRESHOLD" \]; then
  echo "CRITICAL: Replication lag = ${LAG}s (threshold: ${THRESHOLD}s)"
  exit 2
fi
echo "OK: Replication lag = ${LAG}s"
exit 0

## Failover — ręczny i automatyczny z Patroni

\# --- RECZNIE FAILOVER (PostgreSQL 12+) ---

# Na STANDBY: promocja do primary
sudo -u postgres psql -c "SELECT pg\_promote();"
# lub:
sudo -u postgres touch /tmp/promote\_trigger
# (jezeli skonfigurowano promote\_trigger\_file w postgresql.conf)

# Sprawdz ze standby jest teraz primary
sudo -u postgres psql -c "SELECT pg\_is\_in\_recovery();"
# Powinno zwrocic 'f' (false = jest primary)

# Stary primary (jezeli wracamy po naprawie) — zresetuj jako standby
# OPCJA 1: pg\_rewind (szybkie, wymaga ze old\_primary ma wal\_log\_hints = on)
sudo -u postgres pg\_rewind \\
  --target-pgdata=/var/lib/postgresql/16/main \\
  --source-server='host=192.168.1.11 user=replicator password=strong\_repl\_pass dbname=postgres'

# OPCJA 2: pg\_basebackup od nowa (wolniejsze, zawsze dziala)
sudo -u postgres pg\_basebackup -h 192.168.1.11 -U replicator -D /tmp/pgdata\_new -P -R

# --- PATRONI — automatyczny failover z DCS ---
# Patroni uzywa etcd lub Consul do leader election
# Instalacja: sudo pip3 install patroni\[etcd\]
# Konfiguracja: /etc/patroni/patroni.yml

# Po failerze Patroni automatycznie:
# 1. Wykrywa niedostepnosc primary (health check co 10s)
# 2. Przeprowadza elekcje lidera przez etcd
# 3. Promuje najlepszy standby
# 4. Informuje przez REST API o zmianie

# Sprawdz status Patroni
patronictl -c /etc/patroni/patroni.yml list
# + Cluster: postgres-prod (123456789) --------+
# | Member    | Host          | Role    | State   |
# | pg-node1  | 192.168.1.10  | Replica | running |
# | pg-node2  | 192.168.1.11  | Leader  | running |

## Najczęstsze pytania

Czym jest PostgreSQL Streaming Replication? +

Streaming Replication to wbudowany mechanizm replikacji PostgreSQL (od wersji 9.0), w którym standby (replika) pobiera zmiany z primary (mastera) w czasie rzeczywistym przez strumień WAL (Write-Ahead Log). Standby jest ciągłym kopią primary — może służyć do odczytów (hot standby) lub być gotowy do przejęcia roli primary podczas awarii (failover). Jest to replikacja fizyczna: kopiuje bloki danych, nie zapytania SQL.

Co to są replication slots w PostgreSQL? +

Replication slots to mechanizm gwarantujący, że primary nie usunie plików WAL dopóki wszystkie repliki z aktywnym slotem ich nie przetworzą. Bez slotów, jeśli replika jest offline przez długi czas, primary może usunąć potrzebne WAL pliki i replika musi być odtworzona od zera (pg\_basebackup). Wada slotów: jeśli replika jest trwale offline, primary nieograniczenie gromadzi WAL i może skończyć się miejsce na dysku. Monitoruj pg\_replication\_slots.

Jak sprawdzić opóźnienie replikacji PostgreSQL? +

Na primary: SELECT \* FROM pg\_stat\_replication; — pokaże write\_lag, flush\_lag, replay\_lag dla każdej repliki. Na standby: SELECT now() - pg\_last\_xact\_replay\_timestamp() AS replication\_delay; — czas od ostatnio przetworzonej transakcji. Dopuszczalne opóźnienie zależy od wymagań — dla read repliki kilka sekund jest OK, dla repliki używanej do failover powinno być poniżej 1 sekundy.

Jak przeprowadzić failover PostgreSQL? +

Ręczny failover: na standby uruchom pg\_promote() (PostgreSQL 12+) lub utwórz plik trigger\_file (stare wersje). Standby staje się nowym primary. Następnie zmień connection string w aplikacji na nowy primary. Stary primary (jeśli wróci) musi być zresetowany jako standby przez pg\_rewind lub pg\_basebackup. Dla automatycznego failover użyj narzędzi takich jak Patroni (etcd/Consul backend), Repmgr lub pg\_auto\_failover.

## Sprawdź oferty pasujące do tego scenariusza

Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne.

Contabo

VPS z SSD NVMe i dużą ilością RAM — wymagany dla PostgreSQL production

VPS + NVMe

[Aktywuj rabat →](/out/contabo)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/contabo)

Mikr.us

Budżetowy VPS do nauki i testów replikacji PostgreSQL

Dev/Test

[Aktywuj rabat →](/out/mikrus)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/mikrus)

LH.pl

Hosting z zarządzaną PostgreSQL — bez konfiguracji replikacji

Hosting

[Aktywuj rabat →](/out/lh-pl)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/lh-pl)

## Powiązane strony

-   [MySQL Galera Cluster — multi-master](/baza-wiedzy/mysql-galera-cluster)
-   [MySQL replikacja master-slave](/baza-wiedzy/mysql-replication-master-slave)
-   [Bezpieczeństwo VPS — checklist](/baza-wiedzy/bezpieczenstwo-vps-checklist)
-   [Wszystkie artykuły](/baza-wiedzy/)