Port 5432 jest zajęty - jak uruchomić PostgreSQL na innym porcie

PostgreSQL

Port 5432 jest zajęty - jak uruchomić PostgreSQL na innym porcie

W skrócie

Komunikat o zajętym porcie 5432 to jeden z najczęstszych powodów, dla których PostgreSQL nie chce wstać - zwłaszcza gdy na maszynie jest więcej niż jedna instancja. Pokazujemy, jak go zdiagnozować i uruchomić bazę na innym porcie.

Jak to wygląda w praktyce

Próbujemy wystartować PostgreSQL, a usługa natychmiast pada. W logu klastra znajdujemy wpis w rodzaju could not bind IPv4 address "0.0.0.0": Address already in use oraz podpowiedź Is another postmaster already running on port 5432?. Czasem baza w ogóle nie zapisuje logu, bo nie zdążyła wystartować, a menedżer usług raportuje tylko, że proces zakończył się błędem. Typowo dzieje się to, gdy instalujemy drugą wersję PostgreSQL obok istniejącej, gdy stawiamy lokalną instancję deweloperską przy już działającej, albo gdy poprzedni proces bazy nie zamknął się do końca i wciąż trzyma port. Efekt jest jeden: nowa instancja nie ma gdzie nasłuchiwać.

Dlaczego tak się dzieje

Każdy serwer PostgreSQL nasłuchuje połączeń na jednym porcie TCP - domyślnie 5432. Port może w danej chwili należeć tylko do jednego procesu; system operacyjny nie pozwoli drugiemu programowi zająć tego samego portu na tym samym adresie. Jeśli więc na maszynie działa już jakakolwiek instancja PostgreSQL (albo inny program) na 5432, kolejna próba startu na tym porcie musi się nie udać. Najczęstsze scenariusze to dwie zainstalowane wersje PostgreSQL, z których obie chcą domyślny port, albo osierocony postmaster po nieudanym zamknięciu, który wciąż trzyma gniazdo. Rozwiązanie sprowadza się do decyzji: czy proces zajmujący port jest nam potrzebny. Jeśli nie - zwalniamy port. Jeśli tak, a mimo to chcemy drugą instancję - dajemy jej inny port, bo współdzielić się nie da.

Jak to rozwiązać krok po kroku

1. Ustalamy, co trzyma port. Na Linuksie: sudo ss -ltnp | grep 5432 (lub sudo lsof -i :5432). Na Windowsie: netstat -ano | findstr 5432, a numer procesu odszukujemy w Menedżerze zadań. Zobaczymy nazwę i PID procesu nasłuchującego.
2. Sprawdzamy, czy to działająca instancja PostgreSQL, której potrzebujemy. Jeśli tak (np. produkcyjna baza) - nie ruszamy jej, tylko przechodzimy do uruchomienia nowej instancji na innym porcie.
3. Jeśli port trzyma zbędna albo zapomniana instancja, zatrzymujemy ją porządnie usługowo - na systemd na przykład sudo systemctl stop postgresql@16-main - zamiast ubijać proces na siłę. Czysty stop zwalnia port bez ryzyka uszkodzenia danych.
4. Gdy chcemy drugą instancję obok istniejącej, wybieramy wolny port (np. 5433) i ustawiamy go w jej postgresql.conf: port = 5433. Każdy klaster ma własny plik konfiguracyjny w swoim katalogu danych.
5. Alternatywnie port podajemy przy starcie, nie ruszając pliku: pg_ctl -D /sciezka/do/katalogu_danych -o "-p 5433" start. Parametr -o "-p 5433" przekazuje port bezpośrednio do serwera.
6. Startujemy instancję na nowym porcie i sprawdzamy log - komunikat o zajętym adresie nie powinien już wystąpić, a pojawi się wpis o nasłuchiwaniu na wybranym porcie.

Jak sprawdzić, że zadziałało

Potwierdzamy, że nowa instancja nasłuchuje tam, gdzie chcieliśmy: ss -ltnp | grep 5433 pokaże proces PostgreSQL na wybranym porcie. Łączymy się jawnie tym portem: psql -h localhost -p 5433 -U postgres - połączenie powinno wejść do właściwego klastra. Wewnątrz bazy zweryfikujemy port zapytaniem SHOW port;. Jeśli zwalnialiśmy port 5432, sprawdzamy, że po zatrzymaniu zbędnej instancji nowa usługa startuje bez błędu Address already in use i zajmuje 5432 zgodnie z oczekiwaniem. Warto pamiętać, że aplikacje i narzędzia domyślnie celują w 5432 - jeśli przenieśliśmy bazę na inny port, trzeba zaktualizować łańcuchy połączeniowe klientów, inaczej będą pukać w niewłaściwe miejsce.

Wróć do listy: 100 najczęstszych pytań i problemów z PostgreSQL

Sprawdź szkolenie: Administracja, replikacja i tuning baz danych PostgreSQL

To szkolenie może być dofinansowane z KFS lub BUR.

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

Sprawdź szkolenie: Zaawansowana administracja PostgreSQL (HA, DR, monitoring, skalowanie)

To szkolenie może być dofinansowane z KFS lub BUR.

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