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
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.
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.
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.
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)
1
0
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.
2
0
Do sprawdzenia portu usługi uruchomionej na lokalnym hoście lepiej sprawdzi się netstat.
Albo ss -lnt pokazujący otwarte porty tcp w wersji numerycznej.