pgBackRest w klastrze Patroni przestaje robić backup po przełączeniu primary

PostgreSQL

pgBackRest w klastrze Patroni przestaje robić backup po przełączeniu primary

W skrócie

Ten problem dotyczy klastrów Patroni, w których pgBackRest konfigurowano, gdy liderem był jeden konkretny węzeł, i na serwerze kopii wpisano tylko ten węzeł. Dopóki lider się nie zmienia, backupy przechodzą. Po pierwszym przełączeniu ról zadanie backupu kończy się błędem i łatwo to przeoczyć. Odtworzyliśmy ten scenariusz na PostgreSQL 16 i pgBackRest 2.59. Pokażemy komunikaty i konfigurację, która działa niezależnie od tego, który węzeł jest liderem.

Jak to wygląda w praktyce

Po przełączeniu ról backup uruchamiany z serwera kopii kończy się błędem. Gdy dawny lider jest wyłączony:

$ pgbackrest --stanza=patroni backup --type=full
P00   WARN: unable to check pg1: [DbConnectError] unable to connect to ...
P00  ERROR: [056]: unable to find primary cluster - cannot proceed
            HINT: are all available clusters in recovery?

Gdy dawny lider wrócił już jako replika, ostrzeżenia WARN nie ma, bo pgBackRest łączy się z nim bez kłopotu, ale błąd [056] z tą samą podpowiedzią zostaje. Polecenie check zgłasza wtedy ERROR: [027]: primary database not found z podpowiedzią HINT: check indexed pg-path/pg-host configurations.

Zobacz też: Szkolenie Zaawansowana administracja PostgreSQL: High Availability, Disaster Recovery

Dlaczego tak się dzieje

pgBackRest robi backup z udziałem primary: tam wykonuje start i stop kopii, a pliki może czytać z repliki. Który węzeł jest primary, pgBackRest ustala spośród klastrów wpisanych w konfigurację stanzy, czyli nazwanego zestawu ustawień kopii dla jednego klastra PostgreSQL. Opcje pg- są indeksowane: pg1-host, pg1-path, pg2-host i kolejne. Dokumentacja pgBackRest zaznacza, że kolejność nie ma znaczenia, a każdy z nich może być primary albo standby, oraz że tylko konfiguracja hosta repozytorium powinna znać więcej niż jeden PostgreSQL. Jeśli na serwerze kopii jest tylko pg1-host dawnego lidera, po przełączeniu nie ma tam żadnego primary.

Opcja backup-standby=y nie omija problemu, bo według dokumentacji wymaga skonfigurowania zarówno primary, jak i standby. Drugą stroną tego samego problemu jest archiwizacja WAL, czyli kopiowanie plików dziennika zmian do repozytorium: backup czeka na zarchiwizowanie plików WAL z bieżącego primary, więc archive_command z archive-push musi działać na każdym węźle, który może zostać liderem.

Jak to rozwiązać krok po kroku

1. Na serwerze kopii w /etc/pgbackrest.conf wpisz w sekcji stanzy wszystkie węzły Patroni, jak w lekcji:

   [patroni]
   pg1-host=pg1
   pg1-path=/postgres/data
   pg2-host=pg2
   pg2-path=/postgres/data
   pg3-host=pg3
   pg3-path=/postgres/data
   
   [global]
   repo1-path=/backups
   backup-standby=y
   start-fast=y

2. Na każdym węźle Patroni zostaw lokalną konfigurację z samym pg1-path oraz repo1-host wskazującym serwer kopii. Nie dopisuj tam pozostałych węzłów.
3. Ustaw archiwizację w konfiguracji dynamicznej Patroni (patronictl edit-config): w postgresql.parameters parametr archive_command: pgbackrest --stanza=patroni archive-push %p, a w recovery_conf restore_command z archive-get %f %p. Patroni przeładuje konfigurację na wszystkich węzłach, bo archive_command ma kontekst sighup. archive_mode = on ma kontekst postmaster, więc jego zmiana wymaga restartu.
4. Z serwera kopii uruchom pgbackrest --stanza=patroni --log-level-console=info check. Polecenie sprawdza konfigurację repozytorium na replikach, a na primary wymusza przełączenie pliku WAL i sprawdza, czy trafił do archiwum.
5. Wykonaj backup i zobacz w logu, skąd poszedł. Przy backup-standby=y pojawia się linia wait for replay on the standby to reach z numerem LSN, czyli pozycją w WAL. Według dokumentacji wartość y oznacza, że replika jest do backupu wymagana, a aktualna wersja ma też tryb prefer, który przy braku repliki robi kopię z primary.
6. Przetestuj przełączenie w oknie serwisowym: patronictl switchover, a potem ponownie check i backup z serwera kopii, zanim zrobi to harmonogram.

Jak sprawdzić, że zadziałało

Po zmianie konfiguracji check przechodzi wszystkie etapy. U nas po failoverze wyglądało to tak:

P00   INFO: check repo1 (standby)
P00   INFO: check repo1 configuration (primary)
P00   INFO: check repo1 archive for WAL (primary)
P00   INFO: WAL segment 000000020000000000000006 successfully archived to '...' on repo1
P00   INFO: check command end: completed successfully (348ms)

Prefiks 00000002 w nazwie segmentu to nowa oś czasu po przełączeniu, czyli WAL wysyła już nowy lider. Backup z repliki kończy się liniami:

P00   INFO: wait for replay on the standby to reach 0/8000028
P00   INFO: replay on the standby reached 0/8000028
P00   INFO: new backup label = 20261019-182335F
P00   INFO: backup command end: completed successfully (2206ms)

Na koniec pgbackrest --stanza=patroni info pokazuje status: ok i nowy backup na liście.

Powiązane problemy

• Podstawy stanzy, backupu i odtwarzania opisujemy w tekście pgBackRest, czyli backup i odtwarzanie klasy enterprise.
• Jeśli check zgłasza problem z archiwizacją, zajrzyj do tekstu jak skonfigurować ciągłą archiwizację WAL (archive_command).
• Bezpieczne przełączenie lidera do takiego testu opisujemy w tekście jak ręcznie przełączyć rolę primary (switchover) w Patroni.

Wróć do listy: 112 najczęstszych pytań i problemów z PostgreSQL