Blog JSystems - uwalniamy wiedzę!

Szukaj


Jak zarządzać stanem klastra? Zarówno za pomocą PG_CTL, jak i usługi systemowej.









Z tego artykułu dowiesz się:

  • jak sprawdzać stan usługi PostgreSQL,
  • jak zatrzymywać, uruchamiać i restartować PostgreSQL za pomocą pg_ctl,
  • jak zatrzymywać, uruchamiać i restartować PostgreSQL za pomocą usługi,
  • jak ustawić zmienną środowiskową PGDATA, by nie musieć ciągle podawać położenia klastra,
  • jak przeładowywać konfigurację bez restartu klastra.



Uruchamiać, zatrzymywać, restartować i przeładowywać konfigurację usługi możemy na dwa sposoby. Albo wykorzystując pg_ctl, albo systemctl. W pierwszym przypadku jest to skrypt PostgreSQL. W drugim- zarządzamy usługą systemu operacyjnego.


Po wykonaniu wszystkich kroków z instrukcji instalacji PostgreSQL mamy już działającą usługę. Możemy to zweryfikować, wywołując:


systemctl status postgresql-15.service


Uruchamianie, zatrzymywanie i restart za pomocą pg_ctl


Aby uruchamiać, zatrzymywać, restartować czy przeładowywać PostgreSQL za pomocą pg_ctl, przechodzimy najpierw do użytkownika systemowego postgres:


sudo su - postgres

Do startowania i zatrzymywania klastra służy skrypt pg_ctl. Jednak do czasu, aż nie ustawimy zmiennej środowiskowej PGDATA, będziemy musieli wskazać katalog instalacji klastra poprzez przełącznik -D. Startowanie klastra:


pg_ctl -D /data_pg start

Jeśli mamy dodane binaria PostgreSQL do zmiennej środowiskowej PATH użytkownika Postgres, wywołujemy bezpośrednio pg_ctl bez ścieżki do niej. Informacja na temat konfiguracji zmiennej PATH znajduje się w rozdziale o instalacji PostgreSQL. Jeśli nie mamy dodanego katalogu binariów PostgreSQL do PATHa, możemy też uruchamiać pg_ctl (oraz inne skrypty), podając pełną ścieżkę. Dla Ubuntu:


/usr/lib/postgresql/15/bin/pg_ctl -D /data_pg start

Dla CentOSa:


/usr/pgsql-15/bin/pg_ctl -D /data_pg start

Zatrzymywanie klastra to również wywołanie pg_ctl z przełącznikiem -D, ale z argumentem stop w miejscu start:


pg_ctl -D /data_pg stop

Aby zrestartować klaster, wystarczy dać argument restart:


pg_ctl -D /data_pg restart

Możemy też sprawić, że podawanie katalogu instalacji klastra nie będzie konieczne, konfigurując zmienną środowiskową PGDATA. Możemy to zrobić dla aktualnej sesji:


export PGDATA=/data_pg
pg_ctl stop
pg_ctl start
pg_ctl restart

Możliwe jest też skonfigurowanie PGDATA dla wszystkich przyszłych sesji. Wystarczy dodać tę zmienną środowiskową do ~/.bash_profile. Edytujemy plik:


nano ~/.bash_profile

Następnie dodajemy poniższe linijki do tego pliku:


PGDATA=/data_pg
export PGDATA


Po tej czynności wylogowujemy się z użytkownika Postgres i logujemy się ponownie lub uruchamiamy skrypt ~./bash_profile:


. ~/.bash_profile

Możemy teraz sprawdzić, czy zmienna poprawnie się dodała, wywołując:


Echo $PGDATA


Niezależnie od tego, czy ustawiliśmy PGDATA dla sesji czy dla użytkownika, możemy teraz wywoływać pg_ctl bez argumentu -D i wskazywania katalogu domowego PostgreSQL.


pg_ctl stop
pg_ctl start
pg_ctl restart


Pamiętajmy, że jeśli mamy zainstalowane w systemie kilka klastrów równolegle (będą musiały słuchać na innych portach), to pozostałe klastry (poza domyślnym, czyli ustawionym w zmiennej PGDATA) będzie trzeba uruchamiać i zatrzymywać z użyciem przełącznika -D.


Uruchamianie, zatrzymywanie i restart PostgreSQL za pomocą systemctl


Jeśli chcemy mieć klaster w innej lokalizacji niż domyślna „/var/lib/postgresql”, to nie zapomnijmy uaktualnić plik konfiguracyjny usługi “/lib/systemd/system/postgresql-15.service”. Konfiguracja tego pliku została opisana w rozdziale o instalacji PostgreSQL.


Poniższe czynności wykonujemy jako użytkownik systemowy z prawami do sudo!


Startowanie usługi:


sudo systemctl start postgresql-15

Zatrzymywanie usługi:


sudo systemctl stop postgresql-15

Restart usługi:


sudo systemctl restart postgresql-15

Wybierzmy jedną formę startowania i zatrzymywania klastra – pg_ctl albo systemctl. Jeśli uruchomimy usługę z pg_ctl, to systemctl nic nie wie na temat uruchomienia usługi przez pg_ctl.


Sprawdzanie statusu usługi


Jeśli uruchomimy usługę z poziomu systemctl, to również za jego pomocą możemy sprawdzić stan tej usługi:


sudo systemctl status postgresql-15

Tę komendę możemy wydać również bez sudo jako użytkownik postgres.



Jeśli uruchomimy usługę za pomocą pg_ctl, to systemctl powie, że usługa nie działa, ponieważ nie wie o jej uruchomieniu.


Status usługi dla wskazanego PGDATA można sprawdzić też za pomocą pg_ctl status np. (wykonujemy jako użytkownik systemowy postgres):


Pg_ctl -D /data_pg status

Dostaniemy jasną informację:



Pozostaje jeszcze możliwość sprawdzenie otwartego portu za pomocą nmap. W takim przypadku nie ma znaczenia, czy uruchomimy usługę za pomocą pg_ctl czy systemctl. Jeżeli port jest otwarty, zostanie to pokazane. Możemy też sprawdzić, czy w katalogu PGDATA (u nas /data_pg) istnieje plik “postmaster.pid”. Plik ten tworzony jest przy starcie klastra i usuwany przy jego zamykaniu. Jest to taki specjalny znacznik określający, czy instancja związana z tą PGDATA jest już uruchomiona.


Sprawdzenie otwartego portu nmapem:


nmap localhost


Sprawdzenie istnienia pliku pid w katalogu domowym PostgreSQL możemy wykonać, korzystając ze zmiennej środowiskowej PGDATA (o ile ją wcześniej skonfigurowaliśmy) lub podając ścieżkę bezwzględną. Poniższe instrukcje wykonujemy jako użytkownik systemowy postgres bądź inny użytkownik - ale mający uprawnienia do sudo (wtedy instrukcję poprzedzamy “sudo”), to jest kwestia uprawnień do tego katalogu. Wyszukujemy w katalogu wszystkie pliki mające w nazwie “postmaster”:


ls $PGDATA | grep postmaster
ls /data_pg | grep postmaster


Jeśli taki plik istnieje, ta instancja PostgreSQL jest uruchomiona.


Przeładowywanie konfiguracji


Niektóre parametry wymagają do zmiany restartu, inne tylko przeładowania konfiguracji. Restart instancji wiąźe się z czyszczeniem wszystkich buforów, a tego z powodu utraty wydajności bazy chcemy uniknąć. W przypadku wpisów w pg_hba.conf (taki ACL - czyli Access Control List określający kto, na jakich zasadach i do czego ma dostęp) wystarczy przeładowanie konfiguracji w miejsce restartu. W przypadku postgresql.conf (plik z konfiguracją najważniejszych parametrów klastra) jest to zależne od parametru. W postgresql.conf jeśli zmiana jakiegoś parametru wymaga restartu, zostało to przy nim napisane:


Konfigurację możemy przeładować na dwa sposoby: za pomocą pg_ctl i za pomocą psql. W przypadku pg_ctl wywołujemy:


pg_ctl reload

Jeśli nie mamy ustawionego PATHa i PGDATA, trzeba będzie stosownie podać ścieżkę do binarki oraz katalog domowy PostgreSQL który chcemy przeładować.


Dla Ubuntu:


/usr/lib/postgresql/15/bin/pg_ctl -D /data_pg reload

Dla CentOSa:


/usr/pgsql-15/bin/pg_ctl -D /data_pg reload


Konfigurację możemy też przeładować za pomocą psql:


psql -c "select pg_reload_conf()"


Jeśli nie zaktualizowaliśmy zmiennej środowiskowej PATH, dodając do niej binarki PostgreSQL, to musimy podać pełną ścieżkę do psql. Dla Ubuntu:


/usr/lib/postgresql/15/bin/psql -c "select pg_reload_conf()"

Dla CentOSa:


/usr/pgsql-15/bin/psql -c "select pg_reload_conf()"

Komentarze (3)

Musisz być zalogowany by móc dodać komentarz. Zaloguj się przez Google
lech.piekarski 01-10-2024 21:15:18

zgadzam się, że nmap jest kiepskim pomysłem. lepiej netstat -ltp. nmap jest skanerem, który sprawdza otwartość portów sprawdzając każdy po kolei. dodatkowo domyslnie skanowanie ograniczone jest do około 1000 najbardziej popularnych portów więc jeśli postawilibyśmy postgresa na niepopularnym porcie to nmap wogóle by go nie pokazał. netstat bierze natomiast info bezposrednio z sytemu.

fabian.mikolajczak 30-09-2024 20:59:36

Do sprawdzenia portu usługi uruchomionej na lokalnym hoście lepiej sprawdzi się netstat.

mkmorawiec 30-09-2024 20:59:36

Albo ss -lnt pokazujący otwarte porty tcp w wersji numerycznej.

Zaloguj się przez konto Google, aby ocenić komentarz