Głównym narzędziem do zarządzania klastrem patroni jest patronictl. Za jego pomocą możemy między innymi sprawdzić status klastra, wykonać lub zaplanować kontrolowanie przełączenie lidera, zatrzymać lub wznowić automatyczny failover, zreinicjalizować replikę, zmienić konfigurację postgresql dla całego klastra.
Wykonywać patronictl można na dwa sposoby, podając plik konfiguracyjny Patroni lub odnosząc się bezpośrednio do serwera ETCD.
[postgres@centos ~]$ patronictl -c /etc/patroni/config.yml list[postgres@centos ~]$ patronictl -d etcd3://192.168.33.10:2379/ list szkolenie
Konfigurację postgresa w patroni możemy podzielić na trzy kategorie: dynamiczna, lokalna, środowiskowa.
Część dynamiczna jest przechowywana w DCS (Distributed Configuration Store), w naszym przypadku ETCD. Co istotne i warte zapamiętania, parametry te (wypisane poniżej) możemy zmienić tylko i wyłącznie w DCS przez "patronictl edit-config".
Jest to spowodowane tym, że parametry te muszą mieć te same wartości na wszystkich serwerach w klastrze. Patroni przy starcie ignoruje wartości ustawione jako zmienne środowiskowe oraz te w plikach konfiguracyjnych patroni.yaml, postgresql.conf czy postgresql.auto.conf.
Parametry lokalne patroni, ustawione w config.yml, tj. listen_addresses, port, cluster_name oraz hot_standby = on., podobnie jak dynamiczne, mają pierwszeństwo przed postgresql.conf, include_dir oraz postgresql.auto.conf.
Dla zagwarantowania, że nie zostaną przepisane innymi ustawieniami parametry dynamiczne są przekazywane jako parametry uruchomieniowe w "/usr/pgsql-15/bin/postgres", dzięki czemu mają pierwszeństwo.
Możemy to sprawdzić, wywołując instrukcję "ps -ef | grep postgres" na dowolnym serwerze z Patroni. Otrzymany wynik powinien być podobny do poniższego, gdzie widzimy proces postgresa "/usr/pgsql-15/bin/postgres" z zestawem parametrów, z którymi został uruchomiony, i to te wartości nadpisują wszystkie pliki konfiguracyjne, są najwyżej w hierarchii.
[postgres@centos ~]$ ps -ef | grep postgres
postgres 1122 1 0 19:04 ? 00:00:00 /usr/pgsql-15/bin/postgres -D /postgres/data --config-file=/postgres/data/postgresql.conf --listen_addresses=0.0.0.0 --port=5432 --cluster_name=szkolenie --wal_level=replica --hot_standby=on --max_connections=100 --max_wal_senders=5 --max_prepared_transactions=0 --max_locks_per_transaction=64 --track_commit_timestamp=off --max_replication_slots=5 --max_worker_processes=8 --wal_log_hints=on
Podobnie w przypadku konfiguracji pg_hba, najlepiej sprawdza się, jeżeli jest przechowywana w DCS. Inaczej musimy zawsze upewniać się, że edytowaliśmy pg_hba na wszystkich serwerach w klastrze, co przy większych środowiskach może być nieco problematyczne. Jeżeli pg_hba ustawimy w DCS, zostanie ona automatycznie aplikowana kolejno na wszystkich serwerach.
Każda zmiana w DCS, przez patronictl edit-config, jeżeli nie wymaga restartu, jest automatycznie ustawiana, a konfiguracja jest przeładowywana na wszystkich serwerach w klastrze. Zmiany wymagające restartu tworzą oznaczenie "pending restart" dla wszystkich instancji, po czym możemy zaplanować kolejność restartów oraz kiedy przełączyć lidera na inny serwer, w celu aplikowania zmian, minimalizując w ten sposób czas, w którym baza jest niedostępna dla aplikacji.
Przykładowa konfiguracja w "patronictl edit-config". Aby ją wywołać, uruchamiamy "patronictl -c /etc/patroni/config.yml edit-config", możemy zrobić to z dowolnego serwera z patroni. Obowiązuje składnia yaml, każde wcięcie/zagnieżdżenie to dwie spacje lub ich wielokrotność, zawsze liczba parzysta.
patronictl -c /etc/patroni/config.yml edit-configloop_wait: 10
maximum_lag_on_failover: 1048576
postgresql:
parameters:
archive_command: pgbackrest --config=/etc/rdba/pgbackrest/pgbackrest.conf --stanza=patroni archive-push %p
...
<lista parametrów>
...
work_mem: 20MB
pg_hba:
- local all postgres peer
...
- <więcej wpisów>
...
- host all appuser 192.168.1.1/24 md5
- hostssl all appuser 192.168.2.1/24 md5
recovery_conf:
restore_command: pgbackrest --config=/etc/rdba/pgbackrest/pgbackrest.conf --stanza=patroni --pg1-path=/postgres/data archive-get %f %p
use_pg_rewind: true
use_slots: true
retry_timeout: 10
ttl: 30
Po zmianie jakichkolwiek parametrów i wyjściu z edytora, patroni podsumowujemy zmiany i zapytamy o potwierdzenie przed ich aplikowaniem na wszystkich członkach klastra. Jeżeli zmiana wymaga restartu, w statusie patroni "patronictl -c /etc/patroni/config.yml list" zobaczymy dodatkową kolumnę "Pending restart".
Wykonanie lub planowanie switchovera, czyli planowanego przerzucenie roli Lidera na inny serwer w klastrze, możemy przeprowadzić w formie interaktywnej za pomocą "patronictl -c /etc/patroni/config.yml switchover". Patroni podpowie wszystkie możliwości dla wymaganych parametrów dla przełączenia kontrolowanego.
Możemy też wykonać przełączenie kontrolowane bezpośrednio poprzez dodanie przełączników "--master <aktualny master>", "--candidate <nowy master>"oraz jeden z "--scheduled", aby zaplanować przełączenie w przyszłości lub "--force" aby wykonać je natychmiast. Przykładowo:
patronictl -c /etc/patroni/config.yml switchover szkolenie --master pg2 --candidate pg1 --scheduled 2022-11-20T12:00
Zaplanowane przełączenia zobaczymy w widoku statusu klastra, "patronictl -c /etc/patroni/config.yml list"
W podobny sposób możemy wykonać lub zaplanować restart serwerów. W trybie interaktywnym "patronictl -c /etc/patroni/config.yml restart szkolenie" lub dodając szereg przełączników, m.in. "--pending", wszystkie serwery oczekujące restartu, "-r [master|replica|any]", restartujemy wszystkie serwery o wybranej roli oraz "--scheduled" lub "--force", wymuszenie restartu na tej samej zasadzie jak przy kontrolowanym przełączeniu lidera, po prostu restart, bez zbędnych pytań.
patronictl -c /etc/patroni/config.yml restart szkolenie --pending
patronictl -c /etc/patroni/config.yml restart szkolenie -r replica
patronictl -c /etc/patroni/config.yml restart szkolenie --scheduled 2023-08-14T23:00
patronictl -c /etc/patroni/config.yml restart szkolenie --force
Jeżeli chcemy zrezygnować z zaplanowanego restartu lub przełączenia, możemy to wykonać za pomocą patronictl -c /etc/patroni/config.yml flush szkolenie switchover lub restart:
patronictl -c /etc/patroni/config.yml flush szkolenie switchover
patronictl -c /etc/patroni/config.yml flush szkolenie restart
W czasie zaplanowanego okna serwisowego możemy wyłączyć automatyczny failover, aby zapobiec niepotrzebnym przełączeniom lidera, za pomocą polecenia:
patronictl -c /etc/patroni/config.yml pause szkolenie
A następnie wznowić go poprzez:
patronictl -c /etc/patroni/config.yml resume szkolenie
Replika, która odłączyła się od klastra na zbyt długo i nie potrafi się podłączyć ponownie, może wymagać odbudowania. W tym celu możemy skorzystać z polecenia:
patronictl -c /etc/patroni/config.yml reinit szkolenie pg2
Reinit domyślnie usunie zawartość PGDATA, a następnie wykona pg_basebackup z serwera lidera, ale możemy zmienić metodę synchronizacji lub dodać kilka, które będą się wykonywały, jeżeli wcześniejsza metoda się nie powiodła.
Przykład użycia pgbackrest do reinicjalizacji/tworzenia nowych replik:
patronictl -c /etc/patroni/config.yml edit-configpostgresql:
create_replica_methods:
- pgbackrest
- basebackup
pgbackrest:
command: /usr/bin/pgbackrest --stanza=patroni --delta restore --log-level-console=detail
keep_data: true
no_params: true
Parametr keep_data zapobiega wyczyszczeniu PGDATA podczas wykonywania reinicjalizacji, no_params zapobiega dodawaniu przez patroni dodatkowych parametrów do polecenia command. W połączeniu z poleceniem pgbackrest delta restore umożliwi nam odzyskanie z repozytorium tylko tych plików danych, które się zmieniły na podstawie sum kontrolnych, przez co możemy pominąć odzyskiwanie większej części plików z PGDATA.
Informacje na temat statusu patroni możemy również sprawdzać za pomocą REST API. Najpopularniejsze opcje to:
- curl -s http://10.238.0.59:8008/history | jq '.'- curl -s http://10.238.0.59:8008/cluster | jq '.'curl -s -o /dev/null -w "%{http_code}" http://pg2:8008/mastercurl -s -o /dev/null -w "%{http_code}" http://pg2:8008/replicaSprawdzając rolę serwera, REST API zwraca kod http 200, jeżeli zapytanie było trafione, np wysyłając zapytanie czy pg2 jest liderem za pomocą http://pg2:8008/master, podobnie dla http://pg2:8008/replica, jeżeli pg2 byłby repliką. Jeżeli odpytywany serwer pełni inną rolę, odpowiedź zmieni się na 503. Jeżeli serwer ma dodane w tagach "noloadbalance" oraz odpytamy go o /replica, otrzymamy odpowiedź 503, nawet jeżeli wybrany serwer jest repliką. Jest to mechanizm, dzięki któremu możemy wykluczyć wybrane serwery z load balancingu.
Pozostałe możliwości opisane są w dokumentacji https://patroni.readthedocs.io/en/latest/rest_api.html
Komentarze (0)
Brak komentarzy...