[ Do realizacji przykładów z tego rozdziału potrzebujemy hostów 1,2,3,4,5. Należy je przygotować według instrukcji ]

Zacznijmy od upewnienia się, że wszystkie pakiety zostały zainstalowane, a serwery były zrestartowane po aktualizacji. Do wykonania ćwiczeń będziemy potrzebowali 5 serwerów, 3 dla patroni, jeden na repozytorium kopii zapasowych dla pgbackresta oraz jeden dla pgbouncera i haproxy, w kolejnym rozdziale.

[Hosty: 1,2,3,4,5]

Instalacja binarek z rozdziału "Przygotowanie serwerów", strona 3, pomijając inicjalizację klastra.

1. Jeżeli nie posiadamy serwera DNS, pierwszym krokiem powinno być przygotowanie pliku /etc/hosts. Jeżeli korzystamy z serwerów w chmurze, pamiętajmy, by wprowadzać adresy sieci wewnętrznej (np. 10.0.0.4) a nie zewnętrzne! Wewnątrzsieciowy adres ip można sprawdzić, wykonując instrukcję "ip a". Poniższe wykonujemy jako użytkownik systemowy z prawami do sudo - nie postgres:

sudo vi /etc/hosts
<ip serwer1> pg1
<ip serwer2> pg2
<ip serwer3> pg3
<ip serwer4> pgbouncer
<ip serwer5> pgbackup

[Hosty: 1,2,3]

2. Następnym krokiem będzie przygotowanie konfiguracji dla serwera ETCD.

Idealnym rozwiązaniem byłoby posiadanie osobnych serwerów dla ETCD, ale można zainstalować też go na serwerach z Patroni. Powinniśmy zachować nieparzystą liczbę serwerów ETCD oraz najlepiej nieparzystą liczbę serwerowni. Przykładowo 3 serwery w 3 odrębnych lokacjach. Jest to wskazane w celu uniknięcia problemu "split brain", gdzie po krótkich problemach sieciowych możemy skończyć z więcej niż jedną instancją primary.

W sytuacji, gdzie serwer patroni utraci połączenie z większością serwerów ETCD, automatycznie przełączy się w tryb tylko do odczytu, podczas gdy pozostałe serwery rozpoczynają elekcję w celu wybrania najlepszego kandydata na nowego lidera/primary. Warunkiem, aby ETCD dobrze funkcjonowało, jest dostępność n/2+1 serwerów, gdzie n to liczba serwerów w klastrze ETCD. Wynik zaokrąglamy w dół do pełnej wartości, przykładowo 3 / 2 + 1 = 2.5 ≈ 2, więc dla poprawnego działania klastra potrzebujemy 2 serwerów z trzech.

Inicjalizując nowy klaster ETCD, musimy uruchamiać wszystkie serwery pojedynczo. W konfiguracji pierwszego ETCD (/etc/default/etcd) podajemy wartość "ETCD_INITIAL_CLUSTER_STATE" jako "new", aby wskazać, że tworzymy nowy klaster. "ETCD_INITIAL_CLUSTER_TOKEN" to nazwa klastra, a "ETCD_NAME" to nazwa identyfikacyjna serwera ETCD. Wartym wspomnienia jest też parametr "ETCD_INITIAL_CLUSTER", którym określamy spodziewany stan klastra po starcie usługi. Dla pierwszego serwera podajemy tylko jeden serwer, dla drugiego, pierwszy i drugi, dla trzeciego, pierwszy, drugi i trzeci i tak kolejno wpisujemy wszystkie serwery istniejące w klastrze i na końcu serwer który dodajemy. Jest to wymagane tylko podczas pierwszego uruchomienia/dodania każdego serwera ETCD. Późniejsze restarty mogą być wykonywane w dowolnej kolejności, nawet jeżeli któryś z serwerów jest aktualnie niedostępny.

Zależnie od wydajności sieci, możemy chcieć też zwiększyć parametry ETCD odpowiedzialne za wykonywanie hearbeat, sprawdzania czy serwer jest nadal dostępny, oraz czasu który serwer ma na wykonanie elekcji i wybranie nowego lidera. Domyślne wartości są dość niskie, "ETCD_HEARTBEAT_INTERVAL=100" oraz "ETCD_ELECTION_TIMEOUT=500", obie podawane w milisekundach. Aby je zmienić, dodajemy je do pliku konfiguracyjnego w wartości odpowiedniej dla naszej sieci i restartujemy wszystkie serwery ETCD. Warto pamiętać, aby ustawić te parametry wszystkim serwerom na tę samą wartość, ponieważ ETCD posiadając różne wartości dla tych parametrów na różnych serwerach, może czasami się dziwnie zachowywać i timeoutować operacje, które powinny mieć więcej czasu na wykonanie, a co za tym idzie, mogą spowodować nieplanowaną przerwę w działaniu Patroni.

Plik konfiguracyjny jest na każdym serwerze w tej samej lokalizacji. Poniżej przykładowe konfiguracje dla ETCD, które wykorzystamy nieco później. Co ważne, nie wszystkie parametry przyjmują nazwy FQDN, niektóre zezwalają tylko na adresy IP, dlatego dla zachowania spójności konfiguracji, dobrze jest ustawić wszędzie adresy IP. Pamiętajmy też o tym, że hosty powinny być w tej samej podsieci oraz w konfiguracji powinniśmy podać adres IP, który jest przypisany do karty sieciowej na serwerze. Przykładowo, jeżeli korzystamy z hostów na Azure, nie korzystamy z adresów publicznych, przez które logujemy się na serwer, ale z adresów z podsieci, którą stworzyliśmy. Pamiętajmy o otwarciu portów 2379 i 2380 na poziomie firewalla/chmury.

Przechodzimy do edycji plików konfiguracyjnych ETCD. Pamiętajmy o podmianie dla tagów <ip serwer1>, <ip serwer2> i <ip serwer3>:

sudo vi /etc/default/etcd

# pg1 serwer

ETCD_NAME="pg1"
ETCD_INITIAL_CLUSTER="pg1=http://<ip serwer1>:2380"
ETCD_INITIAL_CLUSTER_TOKEN="szkolenie"
ETCD_INITIAL_CLUSTER_STATE="new"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://<ip serwer1>:2380"
ETCD_DATA_DIR="/var/lib/etcd/postgres.etcd"
ETCD_LISTEN_PEER_URLS="http://<ip serwer1>:2380"
ETCD_LISTEN_CLIENT_URLS="http://<ip serwer1>:2379,http://localhost:2379"
ETCD_ADVERTISE_CLIENT_URLS="http://<ip serwer1>:2379"

# pg2 serwer

ETCD_NAME="pg2"
ETCD_INITIAL_CLUSTER="pg1=http://<ip serwer1>:2380,pg2=http://<ip serwer2>:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://<ip serwer2>:2380"
ETCD_DATA_DIR="/var/lib/etcd/postgres.etcd"
ETCD_LISTEN_PEER_URLS="http://<ip serwer2>:2380"
ETCD_LISTEN_CLIENT_URLS="http://<ip serwer2>:2379,http://localhost:2379"
ETCD_ADVERTISE_CLIENT_URLS="http://<ip serwer2>:2379"

# pg3 serwer

ETCD_NAME="pg3"
ETCD_INITIAL_CLUSTER="pg1=http://<ip serwer1>:2380,pg2=http://<ip serwer2>:2380,pg3=http://<ip serwer3>:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://<ip serwer3>:2380"
ETCD_DATA_DIR="/var/lib/etcd/postgres.etcd"
ETCD_LISTEN_PEER_URLS="http://<ip serwer3>:2380"
ETCD_LISTEN_CLIENT_URLS="http://<ip serwer3>:2379,http://localhost:2379"
ETCD_ADVERTISE_CLIENT_URLS="http://<ip serwer3>:2379"

3. Po skonfigurowaniu etcd możemy przejść do restartu usługi na pg1, sprawdzenia statusu oraz dodania pg2 do klastra etcd, jako użytkownik z prawami do sudo. Pamiętajmy o podmianie tagu <ip serwer2>:

sudo systemctl enable etcd
sudo systemctl restart etcd
sudo etcdctl member list
sudo etcdctl member add pg2 http://<ip serwer2>:2380

4. Następnie włączamy autostart oraz restartujemy usługę etcd na pg2:

sudo systemctl enable etcd
sudo systemctl restart etcd

5. Ponownie na pg1 sprawdzamy status członków klastra etcd oraz dodajemy pg3. Pamiętajmy o podmianie tagu <ip serwer3>:

sudo etcdctl member list
sudo etcdctl member add pg3 http://<ip serwer3>:2380

6. Restart usługi etcd na pg3 oraz sprawdzamy stan etcd:

sudo systemctl enable etcd
sudo systemctl restart etcd
sudo etcdctl member list

7. Dla pewności sprawdźmy na wszystkich serwerach PostgreSQL (1,2,3),, czy nie jest uruchomiona żadna instancja postgresa:

systemctl status postgres*
ps -ef | grep postgres

7.1 Jeśli usługa działa, zatrzymajmy ją i wyłączmy jej autostart. Pamiętajmy o podmianie tagu <PGDATA>:

# jeżeli działa jako usługa
sudo systemctl stop postgresql@15-main.service
sudo systemctl disable postgresql@15-main.service


# jeżeli był uruchomiony przez pg_ctl. Wykonujemy jako użytkownik postgres
pg_ctl -D <PGDATA> stop -m fast

8. Podczas konfiguracji Patroni zaleca się włączenia modułu softdog w jądrze linuxa, dlatego musimy go włączyć i skonfigurować na serwerach pg 1,2,3. Patroni może go wykorzystać do przeprowadzenia dodatkowej kontroli serwerów w klastrze i sprawdzić między innymi użycie procesora, pamięci, swapa czy dysku oraz wywołać zdalny restart serwera, który jest przeciążony i nie odpowiada w skonfigurowanym czasie:

sudo sh -c 'echo "softdog" >> /etc/modules'


sudo sh -c 'echo "KERNEL==\"watchdog\", OWNER=\"postgres\", GROUP=\"postgres\"" >> /etc/udev/rules.d/61-watchdog.rules'

8.1 Musimy też sprawdzić, czy moduł jest na czarnej liście modułów, które nie powinny się ładować przy starcie systemu i usunąć go z niej, jeśli się tam znajduje:

Sprawdzenie, czy jest na czarnej liście:

grep blacklist /lib/modprobe.d/* /etc/modprobe.d/* |grep softdog

Usunięcie modułu z czarnej listy. Blacklist w /etc nie zawsze istnieje, dlatego można bezpiecznie przejść dalej, jeżeli polecenie zwróci błąd o nieistniejącym pliku:

sudo sed -i '/blacklist softdog/d' /lib/modprobe.d/blacklist_* 2> /dev/null
sudo sed -i '/blacklist softdog/d' /etc/modprobe.d/blacklist_* 2> /dev/null

Weryfikacja, czy wpisy zostały rzeczywiście usunięte:

grep blacklist /lib/modprobe.d/* /etc/modprobe.d/* |grep softdog

9. Uruchomienie modułu softdog i sprawdzenie, czy wystartuje automatycznie po restarcie:

vagrant@ubuntu:~$ sudo modprobe softdog
vagrant@ubuntu:~$ sudo lsmod | grep softdog
softdog                16384  2


vagrant@ubuntu:~$ sudo reboot

vagrant@ubuntu:~$ sudo lsmod | grep softdog
softdog                16384  2

10. Sprawdzenie, czy postgres jest właścicielem watchdoga, tak jak to ustawiliśmy w #8:

vagrant@ubuntu:~$ ls -l /dev/watchdog*
crw-rw---- 1 postgres postgres  10, 130 Jan 25 12:31 /dev/watchdog
crw-rw---- 1 postgres postgres  10, 130 Jan 25 12:31 /dev/watchdog0

10.1 Jeżeli nie, należy go zmienić:

sudo chown postgres: /dev/watchdog /dev/watchdog0

11. Ostatnią weryfikacją jest to, czy istnieje katalog /var/run/postgresql oraz czy jego właścicielem jest postgres. "mkdir -p" sprawdzi, czy katalog istnieje, jeżeli tak, nie zrobi nic, jeżeli nie istnieje, to zostanie utworzony:

sudo mkdir -p /var/run/postgresql && sudo chown postgres: /var/run/postgresql

12. Teraz możemy przejść do stworzenia plików yml, czyli głównych plików konfiguracyjnych dla patroni.

Opis poszczególnych parametrów:

scope - nazwa klastra Patroni,

name - nazwa serwera wyświetlana przez patroni, np przy sprawdzeniu stanu klastra,

restapi - definicja, na jakich interfejsach sieciowych będzie nasłuchiwało restapi Patroni, w "listen" podajemy, na jakim adresie IP restapi Patroni będzie nasłuchiwało. Jeżeli ustawimy 0.0.0.0, nasłuchiwanie będzie następowało na wszystkich interfejsach sieciowych na serwerze. W connect_address definiujemy, przez który adres IP/hosta Patroni powinno łączyć się do restapi, wykonując kontrole hostów.

etcd - lista serwerów etcd wraz z portami, na których nasłuchują,



bootstrap - sekcja wykorzystywana tylko w momencie tworzenia nowego klastra,

dcs - parametry przechowywane w "Distributed Config Store", czyli w ETCD,

 ttl - (time to live) czas na przejęcie blokady lidera w sekundach. Po przekroczeniu określonego czasu Patroni wywoła automatyczny failover i wybierze nowego lidera,

 loop_wait - częstotliwość sprawdzenia stanu serwerów (healthcheck) w Patroni,

 retry_timeout - timeout dla operacji na DCS (ETCD) i Patroni. Problemy z DCS lub utrata sieci na czas krótszy niż retry_timeout nie spowoduje wywołania automatycznego failovera,

 maximum_lag_on_failover - maksymalny lag na replice w bajtach akceptowalny podczas elekcji na lidera. Tylko serwery z mniejszym lagiem mogą ubiegać się o rolę lidera,



 postgresql - podsekcja parametrów dla postgresa w sekcji bootstrap, parametrów wspólnych dla wszystkich instancji w klastrze,

 use_pg_rewind - czy patroni powinien używać pg_rewind podczas podłączania starego lidera jako repliki, domyślnie nie,

 use_slots - ustawienie, czy Patroni powinien korzystać ze slotów replikacyjnych dla replik, domyślnie tak,

 parameters - ustawienia postgresa, Patroni przepisze plik postgresql.conf ustawieniami podanymi tutaj, ale tylko podczas inicjalizacji,

 recovery_conf - konfiguracja recovery, np. restore_command,



 initdb - sekcja parametrów dla initdb, wykonywana tylko raz podczas inicjalizacji klastra, tutaj zmiana kodowania na UTF-8 i dodatkowe ustawienie sum kontrolnych dla bloków danych w celu zwiększenia trwałości danych oraz umożliwieniu korzystania z opcji "delta restore" przez pgbackresta, który działa właśnie na sumach kontrolnych.



 pg_hba - domyślna konfiguracja pg_hba dla klastra po inicjalizacji, tutaj w sekcji bootstrap, zostanie zapisana tylko raz. Aby zarządzać wpisami do pg_hba centralnie za pomocą DCS (ETCD), możemy dodać tę podsekcję do sekcji postgres lub po inicjalizacji, za pomocą "patronictl edit-config".



postgresql - ponownie sekcja postgresql, tym razem poza "bootstrapem", zawiera parametry indywidualne dla każdego klastra postgresa, takie jak listen_address, data_directory,

 authentication - lista użytkowników wykorzystywanych do replikacji, zarządzania i monitoringu klastra lub pg_rewind, wartości, jakie przyjmuje to odpowiednio: replication, superuser, rewind. Tutaj też możemy ustawić nazwy i hasła dla użytkowników, którzy zostaną utworzeni automatycznie po zainicjalizowaniu klastra. A później będą wykorzystywane przez patroni do łączenia się z postgresem, w celu wykonywania kontroli instancji. Hasła powinniśmy ustawić te same we wszystkich plikach konfiguracyjnych, a po zmianie hasła w postgresie powinniśmy zaktualizować hasła w plikach .yml na wszystkich serwerach. Jeżeli podczas wykonywania przykładów zostaniemy zapytani o hasło postgresa, podajemy to z sekcji:

postgresql:
  authentication:
    superuser:
      username: postgres
      password: haslo_postgres

watchdog - sekcja, w której konfigurujemy, czy Patroni ma korzystać z watchdoga, czy też nie,

 mode - tryb, w jakim watchdog jest wykorzystywany, możliwe opcje to "required", patroni nie pozwoli na mianowanie serwera liderem, jeżeli watchdog nie jest uruchomiony, "automatic" Patroni skorzysta z watchdoga, jeżeli ten będzie dostępny, ale będzie też działał bez niego, oraz "off", watchdog wyłączony,

device - ścieżka do urządzenia wykorzystywanego przez watchdoga, przykładowo: /dev/watchdog,

safety_margin - czas w sekundach, po jakim watchdog zainicjuje restart serwera, jeśli serwer przestaje odpowiadać,



tags - etykiety, którymi możemy kontrolować zachowanie względem poszczególnych serwerów

 nofailover - po ustawieniu wartości na true patroni nie będzie brało pod uwagę tego serwera podczas elekcji nowego lidera, domyślnie false,

 clonefrom - jeżeli wartość ustawimy na true, patroni w momencie reinicjalizacji, lub podczas dodawania nowego serwera, będzie próbował wykonać pg_basebackup z tego serwera, domyślna wartość to false, przy której Patroni wykonuje kopię katalogu z danymi z lidera,

 noloadbalance - zmienia odpowiedź repliki odpytanej przez loadbalancer za pomocą REST API czy przyjmuje zapytania tylko do odczytu, po ustawieniu na true, replika odpowiada kodem HTTP 503, domyślnie tag ustawiony jest na false, co zmienia kod odpowiedzi z 503 na 200,

 replicatefrom - parametr umożliwiający konfigurację replikacji kaskadowe, możemy wskazać nazwę serwera, z którego wybrana replika ma replikować zmiany,

 nosync - jeżeli ustawimy wartość tego tagu na true, patroni nigdy nie wybierze tego serwera na synchroniczną replikę, domyślna wartość to false.

Przykładowy konfig dla pg1 poniżej, dla pg2 i pg3 musimy go dopasować (zmodyfikować odpowiednio w pogrubionym czerwonym miejscu). Pamiętajmy też o podmianie adresów IP w sekcji pg_hba. Możemy też ustawić hasła dla tworzonych użytkowników w sekcji authentication:

sudo vi /etc/patroni/config.yml


scope: szkolenie
name: pg1

restapi:
  listen: 0.0.0.0:8008
  connect_address: pg1:8008

etcd:
  hosts: pg1:2379,pg2:2379,pg3:2379

bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576
    postgresql:
      use_pg_rewind: true
      use_slots: true
      parameters:
        wal_level: replica
        password_encryption: md5
        hot_standby: "on"
        logging_collector: 'on'
        max_wal_senders: 5
        max_replication_slots: 5
        wal_log_hints: "on"
        archive_mode: "on"
        archive_timeout: 600s
        archive_command: 'pgbackrest --config=/etc/pgbackrest.conf --stanza=patroni archive-push %p'
      recovery_conf:
        restore_command: 'pgbackrest --config=/etc/pgbackrest.conf --stanza=patroni --pg1-path=/postgres/data archive-get %f %p'

  initdb:
  - encoding: UTF8
  - data-checksums

  pg_hba:
  - local all postgres peer
  - host replication replicator <ip serwer1>/32 md5
  - host replication replicator <ip serwer2>/32 md5
  - host replication replicator <ip serwer3>/32 md5
  - host all all <ip serwer1>/32 md5
  - host all all <ip serwer2>/32 md5
  - host all all <ip serwer3>/32 md5
  - host all all <ip serwer4>/32 md5
  - host all all <ip serwer5>/32 md5

postgresql:
  listen: 0.0.0.0:5432
  connect_address: pg1:5432
  data_dir: "/postgres/data"
  bin_dir: "/usr/lib/postgresql/15/bin"
  pgpass: /tmp/pgpass0
  authentication:
    replication:
      username: replicator
      password: haslo_replikacja
    superuser:
      username: postgres
      password: haslo_postgres
  parameters:
    unix_socket_directories: '/var/run/postgresql'

watchdog:
  mode: required
  device: /dev/watchdog
  safety_margin: 5

tags:
    nofailover: false
    noloadbalance: false
    clonefrom: false
    nosync: false

13. Upewnijmy się, że katalog PGDATA / data_dir, który wybraliśmy, istnieje, ma odpowiedniego właściciela oraz uprawnienia. Ponownie korzystamy z "mkdir -p", który sprawdzi, czy katalog istnieje. Jeżeli tak, nie zrobi nic, a jeżeli nie istnieje, to zostanie utworzony.

sudo mkdir -m 700 -p /postgres/data && sudo chown postgres: /postgres/data

14. Włączamy autostart dla usługi patroni, edytujemy plik serwisu oraz restartujemy usługę:

sudo systemctl enable patroni

Patroni może mieć czasem problem z uruchomieniem po nieplanowanym wyłączeniu serwera i nieprawidłowym jego wystartowaniu. Najczęstsze problemy ze startem patroni to softdog (watchdog), który nie wystartował, nieprawidłowy właściciel plików /dev/watchdog*, brakujący katalog na plik .pid i socketa czy nieprawidłowy właściciel tego katalogu. Zmiany te mogą się pojawić np. po patchowaniu systemu. Aby im zapobiec, możemy dodać poniższe wiersze do konfiguracji usługi patroni:

sudo systemctl edit patroni
[Service]
ExecStartPre=/usr/bin/sudo /sbin/modprobe softdog
ExecStartPre=/usr/bin/sudo /bin/chown postgres: /dev/watchdog /dev/watchdog0
ExecStartPre=/usr/bin/sudo /bin/mkdir -p /var/run/postgresql
ExecStartPre=/usr/bin/sudo /bin/chown postgres: /var/run/postgresql

Jeżeli dodaliśmy którąś z powyższych opcji do konfiguracji, musimy zezwolić użytkownikowi postgres wykonywać te polecenia. Otwórzmy plik sudoers:

sudo visudo

Dodajmy na końcu linię:

postgres ALL=NOPASSWD: ALL

Po nadaniu uprawnień możemy wystartować Patroni.

sudo systemctl restart patroni

15. Powtórzmy kroki konfiguracji patroni na pozostałych serwerach i sprawdźmy status klastra za pomocą patronictl:

patronictl -c /etc/patroni/config.yml list
+ Cluster: szkolenie (7167483141895915465) ----------+
| Member | Host | Role    | State   | TL | Lag in MB |
+--------+------+---------+---------+----+-----------+
| pg1    | pg1  | Replica | running |  1 |           |
| pg2    | pg2  | Replica | running |  1 |         0 |
| pg3    | pg3  | Leader  | running |  1 |         0 |
+--------+------+---------+---------+----+-----------+

16. Zweryfikujmy, czy klaster rzeczywiście działa, czy zadane ustawienia pg_hba działają, czy użytkownik został stworzony z odpowiednim hasłem i czy dane są replikowane na pozostałe serwery. Podłączmy się do serwera z rolą lidera, czyli instancji "primary" z dowolnego serwera:

vagrant@ubuntu:~$ psql -h pg3 -U postgres postgres -c "select pg_is_in_recovery();create table test_replikacji(a text);insert into test_replikacji values ('test');"
Password for user postgres:


 pg_is_in_recovery
-------------------
 f
(1 row)

CREATE TABLE
INSERT 0 1

Wartość 'f' zwrócona przez funkcję "select pg_is_in_recovery();" oznacza, że klaster nie jest w trybie recovery i że jest to nasz serwer primary.

Teraz sprawdźmy, czy tabela jest widoczna na pozostałych serwerach oraz czy zawiera wartość dodaną insertem:

vagrant@ubuntu:~$ psql -h pg2 -U postgres postgres -c "select pg_is_in_recovery(); select * from test_replikacji;"
Password for user postgres:
 pg_is_in_recovery
-------------------
 t
(1 row)


  a
------
 test
(1 row)

Tutaj wartość 't' dla "select pg_is_in_recovery();" oznacza, że instancja jest w trybie odtwarzania zmian, tzn. jest repliką i zwraca poprawną wartość ze stworzonej tabeli. Czyli replikacja działa poprawnie