PostgreSQL "Connection refused": vai serveris darbojas? Kā to noskaidrot

PostgreSQL "Connection refused" ir klienta paziņojums, ka uz šīs adreses un porta neviens nepieņēma tā savienojumu. Tā nav autentifikācijas vai tiesību kļūda: PostgreSQL jūsu pieprasījumu nemaz neredzēja. Labā ziņa ir tā, ka cēloņu saraksts ir īss un parasti pietiek ar četrām komandām, lai saprastu, kurš no tiem ir jūsējais.

Pilno ziņojumu ģenerē libpq, tāpēc psql, lielākā daļa draiveru un daudzi rīki izdrukā to pašu tekstu. Pašreizējās versijās tas izskatās šādi:

$ psql -h 10.0.1.20 -U app appdb
psql: error: connection to server at "10.0.1.20", port 5432 failed: Connection refused
	Is the server running on that host and accepting TCP/IP connections?

$ psql appdb
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory
	Is the server running locally and accepting connections on that socket?

Otrā rinda ir mājiens, nevis diagnoze. libpq pirmkods drukā "Is the server running on that host and accepting TCP/IP connections?" jebkurai šāda veida TCP kļūmei un soketa variantu lokāliem savienojumiem. Ja serveri sasniedzat un tas jūs noraida, saņemat citu kļūdu, piemēram, tās, kas aprakstītas mūsu pg_hba.conf ieraksta ceļvedī.

Atteikts, taimauts vai noraidīts: trīs dažādas problēmas

• Connection refused: hosts atbildēja, bet uz šī porta neviens neklausās vai ugunsmūris aktīvi noraida paketi. Serveris nedarbojas, klausās citur vai uz cita porta.
• Taimauts: atbildes nav vispār. Parasti ugunsmūris vai drošības grupa klusi izmet trafiku, nepareiza IP adrese vai maršrutēšanas problēma.
• FATAL: the database system is starting up (vai shutting down, in recovery mode, not yet accepting connections): jūs sasniedzāt PostgreSQL, bet tas nav gatavs. Tieši šeit lielas datubāzes pēc avārijas pavada lielāko daļu "dīkstāves", skatīt zemāk.

Pārbaude ar četrām komandām

# 1. vai serveris vispār atbild? (0 ok, 1 atsaka, 2 nav atbildes)
pg_isready -h 10.0.1.20 -p 5432; echo $?

# 2. datubāzes hostā: vai kaut kas klausās, un kur?
ss -ltnp | grep 5432
ss -lx  | grep PGSQL

# 3. vai serviss darbojas, un ko tas ierakstīja žurnālā?
systemctl status postgresql
journalctl -u postgresql --since "30 min ago"

# 4. kur serveris uzskata, ka tam jāklausās?
psql -c "SHOW listen_addresses" -c "SHOW port" -c "SHOW unix_socket_directories"

pg_isready ir ātrākais pirmais solis: tas atgriež 0, ja serveris pieņem savienojumus, 1, ja tos noraida (piemēram, starta laikā), 2, ja atbildes nav, un 3, ja mēģinājums netika veikts nepareizu parametru dēļ. Izejas kods 1 un izejas kods 2 ved uz pilnīgi atšķirīgu izmeklēšanu.

Biežākie cēloņi

1. PostgreSQL nedarbojas. Tas avarēja, tika apturēts vai neizdevās startēt. Servisa statuss un servera žurnāls pasaka, kas tieši. Bieži iemesls, kāpēc tas nestartē, ir pilns disks, skatīt PostgreSQL disks pilns: pg_wal. Citi biežie ir drukas kļūda postgresql.conf, novecojis postmaster.pid pēc nekorektas apturēšanas vai trūkstošs datu katalogs, jo sējums netika piemontēts.
2. Tas klausās tikai uz localhost. Noklusējuma listen_addresses ir localhost, kas atļauj tikai loopback TCP savienojumus. Attālie klienti saņem "Connection refused", līdz pievienojat servera adresi vai *. Šo parametru nolasa tikai servera startā, tāpēc reload neko nedara.
3. Nepareizs ports. Noklusējums ir 5432, bet otrs klasteris tajā pašā hostā (bieži Debian un Ubuntu pēc jaunināšanas) bieži darbojas uz 5433. ss -ltnp parāda, kas patiešām ir piesaistīts.
4. Nepareizs soketu katalogs. Lokāliem savienojumiem klientam un serverim jāsakrīt par unix_socket_directories. Dokumentācijā teikts, ka noklusējums parasti ir /tmp, bet to var mainīt kompilēšanas laikā, un Debian saimes pakotnes izmanto /var/run/postgresql. Klients, kas kompilēts vienam izkārtojumam, un serveris, kas kompilēts citam, dod "No such file or directory", lai gan PostgreSQL darbojas. Izmantojiet -h /ceļš/uz/soketu/katalogu, lai norādītu klientam pareizo vietu.
5. Ugunsmūris pa vidu. Hosta ugunsmūris, mākoņa drošības grupa, Kubernetes tīkla politika. Noraidošs noteikums izskatās kā "refused", izmetošs noteikums izskatās kā taimauts.

# postgresql.conf (nepieciešams restarts, reload nepietiek)
listen_addresses = 'localhost,10.0.1.20'   # noklusējums ir 'localhost'
port = 5432

Smalks gadījums: adreses startā vēl nebija

Dokumentācijā norādīts, ka, ja listen_addresses nav tukšs, serveris startē, ja vien var klausīties vismaz uz vienas adreses, un par tām, kuras nevar atvērt, izdod tikai brīdinājumu. Ja PostgreSQL startē, pirms ir gatava virtuālā IP adrese, papildu saskarne vai mākoņa tīkla pievienojums, tas var sākt darbu tikai uz localhost un atteikt katram attālajam klientam, kamēr systemctl status rāda, ka tas darbojas. Meklējiet šo brīdinājumu starta žurnālā un lieciet servisam gaidīt vajadzīgo tīklu.

Kas mainās lielās datubāzēs: atjaunošana pēc avārijas prasa laiku

Noslogotā daudzterabaitu datubāzē visbiežākais iemesls, kāpēc klienti pēc incidenta nevar pieslēgties, nav konfigurācijas kļūda. Serveris atskaņo WAL. Pēc avārijas PostgreSQL jāatkārto viss, kas rakstīts kopš pēdējā kontrolpunkta, pirms tas pieņem savienojumus. Šajā laikā klienti redz the database system is starting up vai "Connection refused", ja postmaster vēl nav augšā, piemēram, kamēr uzraugs to vēl restartē.

LOG:  database system was interrupted; last known up at ...
LOG:  redo starts at 3A/1C000028
LOG:  redo in progress, elapsed time: 10.01 s, current LSN: 3A/5F2D1B40
LOG:  redo in progress, elapsed time: 20.02 s, current LSN: 3A/A1E09C88
...
LOG:  database system is ready to accept connections

• Sekojiet progresam, nerestartējiet. Kopš PostgreSQL 15 log_startup_progress_interval (pēc noklusējuma 10 s) drukā "redo in progress" rindas ar pašreizējo LSN. Ja LSN mainās, atjaunošana strādā. Ja to nogalina un restartē, parasti tas pats WAL jāatkārto vēlreiz no pēdējā kontrolpunkta.
• Atjaunošanas laiks seko kontrolpunktu iestatījumiem. WAL dokumentācijā paskaidrots, ka checkpoint_timeout un max_wal_size samazināšana padara kontrolpunktus biežākus un atjaunošanu pēc avārijas ātrāku, bet ar lielāku lapu izrakstīšanas izmaksu. Serveriem, kas rakstīšanas caurlaidībai noskaņoti ar ļoti lielu max_wal_size, atjaunošana var prasīt daudz ilgāku laiku. Ziniet šo skaitli, pirms tas jums vajadzīgs.
• Pārbaudiet uzraugus. Veselības pārbaudes, Kubernetes liveness pārbaudes, klasteru pārvaldnieki un servisu taimauti, kas sagaida, ka datubāze startēs dažās sekundēs, var nogalināt atjaunošanu, kurai vajag daudzas minūtes, un ilgs starts pārvēršas bezgalīgā ciklā. Iestatiet tiem taimautus, kas atbilst jūsu reālajam atjaunošanas laikam.
• Rezerves serveriem ir savi stāvokļi. Replika, kas vēl nav sasniegusi konsekventu stāvokli, atbild the database system is not yet accepting connections ar detaļu "Consistent recovery state has not been yet reached." Tikai lasīšanas klienti, kas vērsti uz to, neizdosies, līdz tā to sasniegs.
• Dodiet priekšroku failover, nevis gaidīšanai. Ja jums ir vesels rezerves serveris, tā paaugstināšana bieži ir ātrāka nekā gaidīt, kamēr liels primārais pabeigs atjaunošanu pēc avārijas. Plānojiet šo lēmumu iepriekš, ar izolēšanu (fencing), lai vecais primārais neatgrieztos kā otrs rakstītājs.