Avad kihi QGIS-is ja see joonistub. Kolleeg samas VPN-is saab sama kihi jaoks vea. Keegi järeldab, et VPN on katki, ja järgmine tund kulub andmebaasi teisaldamisele või pordi avamisele, mida kumbki neist kunagi ei vajanud. Töölaua päring ja päring, mille GeoServer PostGISile teeb, lahkuvad eri masinatest, eri võrgu-nimeruumidest, eri volitustega. Nende kahe tee eraldamine on suurem osa diagnoosist.

Kaks ühendust, kaks päritolu

QGIS  ->  client's permitted path (often the VPN)  ->  GeoServer listener
GeoServer -> server's permitted path  ->  PostGIS listener

Teine nool ei päri esimese arvuti tunnelit. Konteineris oleval GeoServeril on konteineri võrgupino, mitte hosti oma, ja silla-võrgus oleval konteineril võib olla juurdepääs andmebaasile, mida host ei saa, või vastupidi. Nii võib sama kasutaja ühes sessioonis õnnestuda ja ebaõnnestuda, sõltuvalt sellest, kas vastus tuli vahemälust või värskest päringust.

What you testedWhat it proves
Portal page or GetCapabilitiesHTTP reachability to GeoServer only
A tile served from cachenothing about the database
GetMap for an uncached layera datastore query had to happen

Leia samm, mis tegelikult ebaõnnestus

Teenusetasandi tagasilükkamine, pildipäring, mis ei jõua oma andmehoidlani, ja ühe kihi õigusprobleem näevad brauseri vahekaardil sarnased välja ja serveri logis täiesti erinevad. Küsi konkreetset toimingut ja loe seejärel GeoServeri enda sündmust sama ajatempli jaoks.

curl -s -o /dev/null -w '%{http_code}\n' \
  "https://gis.example.com/geoserver/wms?service=WMS&version=1.3.0&request=GetCapabilities"

curl -s -o /tmp/tile.png -w '%{http_code} %{size_download}\n' \
  "https://gis.example.com/geoserver/wms?service=WMS&version=1.3.0&request=GetMap&layers=corp:parcels&bbox=-13650000,4500000,-13600000,4550000&width=256&height=256&srs=EPSG:3857&format=image/png"

Teise päringu 200 usutava pildiga tõestab, et andmehoidla vastas. 200 teenuse erindi dokumendiga tõestab, et ei vastanud, ja erindi tekst nimetab tavaliselt hoidlat, mitte klienti.

Loe andmehoidlat serveri poolelt

GeoServeri PostGISi viide loetleb, mida hoidla vajab: host, port, andmebaas ja volitused. Kõik see kirjeldab ühendust, mille GeoServer avab. Miski sellest ei kirjelda töölauakliendi sisselogimist. Loe neid nelja välja väitena serveri võrgukonteksti kohta ja kogu „nende juures see töötab“ piletite klass muutub käsitletavaks.

Sellepärast on localhost andmehoidlas nii tavaline viga. See tähendab GeoServeri protsessi enda võrgukonteksti. Kui GeoServer jookseb Dockeris, samal ajal kui PostGIS jookseb hostil, localhost osutab konteineri sisse ega leia midagi, ja ükski VPN-i seadistus ei muuda seda.

Kontrolli serveris marsruuti, kuulajat ja autentimispoliitikat selles järjekorras. PostgreSQLi hostipõhine autentimine sobitab allikaaadressi, mida see näeb, mille lüüs võib tõlkida, seega kliendi VPN-i basseini lisamine HBA-faili parandab serveripoolset ühendust harva. Testi nii, nagu server teeks: sama host, sama port, sama kasutaja. Kui see test õnnestub, samal ajal kui GeoServer ikka ebaõnnestub, on erinevus protsessi kontekstis, mitte andmebaasis.

ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'

Basseinid ja vahemälud hoiavad olekut üle muudatuste

Andmehoidla ühendusbasseinid hoiavad sokette avatuna. Tunnel, mis tuli üles tund pärast basseini loomist, ei anna basseinile tingimata uut teed, ja jõudeolev ühendus võib jääda surnud marsruudile, kuni valideerimine või aegumine selle lõpetab. Kontrolli paigaldatud hoidla valideerimisseadeid, selle asemel et taastumist eeldada, ja väldi kiusatust kogu teenust enne uuesti käivitada, kui tead, milline kiht ebaõnnestus.

Plaadivahemälud loovad selle probleemi peegelpildi: need võivad serveerida õigesti näivat kaarti kaua pärast seda, kui andmebaasiühendus katkes. Vahemälu tühjendamine, et „vaadata, kas see aitab“, hävitab ainsa tõendi, mis oleks sulle öelnud, milline tee oli elus.

Anna üle, mõlemad päritolud nimetatud

Kirjeldus, mis toob kiire paranduse, nimetab kahte asja: kliendipäring, mis jõudis GeoServerini, ja taustatoiming, mida GeoServer ei suutnud lõpetada. Mõlemaga saab õige omanik parandada tee, mis ebaõnnestus. Ainult esimesega on loomulik parandus avada andmebaas avalikult, mis lahendab pileti, luues hullema probleemi.

Märgi üles kiht, vastusekood, serveripoolne erind ja konteiner või host, mis selle tekitas. Need on neli rida ja need kõrvaldavad ebamäärasuse täielikult.

Seotud artiklid