# PostgreSQL: bezpieczne start/stop/restart klastra - roznice miedzy trybami

Zatrzymanie PostgreSQL to nie zawsze proste 'stop' - tryb smart, fast i immediate dzialaja zupelnie inaczej wobec aktywnych polaczen. Pokazujemy, ktorego uzyc w jakiej sytuacji.

Start/stop, w skrócie

Sterowanie klastrem:

```
pg_ctl start -D /sciezka/do/data
pg_ctl stop -m fast -D /sciezka/do/data

systemctl restart postgresql
```

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

  

|  |  |  |  |
| --- | --- | --- | --- |
| [Ikona pliku PDF do pobrania   Cheatsheet](https://jsystems.pl/nowy_blog/download/postgresql/cheatsheety/020_Uruchamianie_zatrzymywanie_i_restart_PostgreSQL_cheatsheet.pdf) | [Ikona notatek   Cheatsheet edytowalny](https://jsystems.pl/nowy_blog/download/postgresql/cheatsheety/020_Uruchamianie_zatrzymywanie_i_restart_PostgreSQL_cheatsheet.docx) | [Ikona ćwiczenia   Ćwiczenie](https://jsystems.pl/nowy_blog/download/postgresql/cwiczenia/020_Uruchamianie_zatrzymywanie_i_restartowanie_PostgreSQL_cwiczenie.pdf) | [Ikona wskazówki   Rozwiązanie ćwiczenia](https://www.youtube.com/watch?v=DsJAQUvHPzA&feature=youtu.be) |

  

**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 i zatrzymywanie PostgreSQL: ilustracja poglądowa](https://jsystems.pl/nowy_blog/img/postgresql_adm/20/10.png)

### 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
```

![Uruchamianie, zatrzymywanie i restart za pomocą pg_ctl: Uruchamianie i zatrzymywanie PostgreSQL](https://jsystems.pl/nowy_blog/img/postgresql_adm/20/20.png)

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
```

![Uruchamianie, zatrzymywanie i restart za pomocą pg_ctl: Uruchamianie i zatrzymywanie PostgreSQL (2)](https://jsystems.pl/nowy_blog/img/postgresql_adm/20/30.png)

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
```

![Uruchamianie, zatrzymywanie i restart za pomocą pg_ctl: Uruchamianie i zatrzymywanie PostgreSQL (3)](https://jsystems.pl/nowy_blog/img/postgresql_adm/20/40.png)

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.

![Sprawdzanie statusu usługi: Uruchamianie i zatrzymywanie PostgreSQL](https://jsystems.pl/nowy_blog/img/postgresql_adm/20/50.png)

**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ę:

![Sprawdzanie statusu usługi: Uruchamianie i zatrzymywanie PostgreSQL (2)](https://jsystems.pl/nowy_blog/img/postgresql_adm/20/60.png)

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
```

![Sprawdzanie statusu usługi: Uruchamianie i zatrzymywanie PostgreSQL (3)](https://jsystems.pl/nowy_blog/img/postgresql_adm/20/70.png)

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
```

![Sprawdzanie statusu usługi: Uruchamianie i zatrzymywanie PostgreSQL (4)](https://jsystems.pl/nowy_blog/img/postgresql_adm/20/80.png)

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
```

![Przeładowywanie konfiguracji: Uruchamianie i zatrzymywanie PostgreSQL](https://jsystems.pl/nowy_blog/img/postgresql_adm/20/90.png)

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

```
psql -c "select pg_reload_conf()"
```

![Przeładowywanie konfiguracji: Uruchamianie i zatrzymywanie PostgreSQL (2)](https://jsystems.pl/nowy_blog/img/postgresql_adm/20/100.png)

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()"
```

[![Baner szkolenia Administracja, replikacja i tuning baz danych PostgreSQL w JSystems, terminy gwarantowane](https://jsystems.pl/new_page_resources/images/other/pgadm1.jpg)](https://jsystems.pl/szkolenia-postgresql;administracja_bazami_danych_postgresql_z_elementami_ha__optymalizacji_i_replikacji.szczegoly?utm_source=blog&utm_medium=article&utm_campaign=post246&utm_content=banner)

[Szkolenie Administracja, replikacja i tuning baz danych PostgreSQL →](https://jsystems.pl/szkolenia-postgresql;administracja_bazami_danych_postgresql_z_elementami_ha__optymalizacji_i_replikacji.szczegoly?utm_source=blog&utm_medium=article&utm_campaign=post246&utm_content=link)

To szkolenie może być [dofinansowane dla Ciebie z KFS lub BUR](https://jsystems.pl/dofinansowanie?utm_source=blog&utm_medium=article&utm_campaign=post246&utm_content=dofinansowanie).

★★★★★Średnia ocena naszych szkoleń w Google: **5/5**

## Powiązane artykuły

- ›[Kurs administracji PostgreSQL - wybór preworka](https://jsystems.pl/blog/show_post/kurs_administracji_postgresql_-_wybor_preworka)
- ›[PG\_CRON - czyli cykliczne uruchamianie zadań w PostgreSQL](https://jsystems.pl/blog/show_post/PG_CRON_-_czyli_cykliczne_uruchamianie_zadań_w_PostgreSQL)
- ›[PostgreSQL - Najważniejsze pojęcia](https://jsystems.pl/blog/show_post/postgresql_-_najwazniejsze_pojecia)
- ›[Kurs administracji PostgreSQL](https://jsystems.pl/blog/show_post/bezplatny_kurs_administracji_postgresql)
- ›[PG\_PREWARM - prosty i szybki tuning w PostgreSQL](https://jsystems.pl/blog/show_post/PG_PREWARM_-_prosty_i_szybki_tuning_w_PostgreSQL)
- ›[PostgreSQL - PG\_REPACK : przenoszenie, przebudowa i klastrowanie tabel i indeksów](https://jsystems.pl/blog/show_post/postgresql_-_pg_repack__przenoszenie_przebudowa_i_klastrowanie_tabel_i_indeksow_online)