GeoServer և PostGIS. կարևորը սերվերի VPN ուղին է
Ձեր նոթբուքի՝ GeoServer հասնելը ոչինչ չի ասում այն մասին, թե արդյոք GeoServer-ը հասնում է PostGIS։ Համեմատեք երկու աղբյուրները, քեշի սահմանը և տվյալների պահոցի սեփական աղբյուրը։
Դուք բացում եք շերտը QGIS-ում և այն գծվում է։ Նույն VPN-ում գտնվող գործընկերը սխալ է ստանում նույն շերտի համար։ Ինչ-որ մեկը եզրակացնում է, որ VPN-ը փչացած է, և հաջորդ ժամը անցնում է տվյալների բազա տեղափոխելու կամ պորտ բացելու վրա, որը երբեք դրա կարիքը չի ունեցել։ Սեղանադիրից եկող հարցումը և այն հարցումը, որ GeoServer-ը անում է PostGIS-ին, դուրս են գալիս տարբեր մեքենաներից, տարբեր ցանցային անվանատարածքներից, տարբեր հավատարմագրերով։ Այս երկու ուղիներն առանձնացնելը ախտորոշման մեծ մասն է։
Երկու միացում, երկու աղբյուր
QGIS -> client's permitted path (often the VPN) -> GeoServer listener
GeoServer -> server's permitted path -> PostGIS listenerԵրկրորդ սլաքը չի ժառանգում առաջին համակարգչի թունելը։ Կոնտեյներում GeoServer-ն ունի կոնտեյների ցանցային կույտը, ոչ թե հոսթի, և կամրջված ցանցում գտնվող կոնտեյները կարող է հասնել տվյալների բազայի, որին հոսթը չի հասնում, կամ հակառակը։ Այսպիսով նույն օգտատերը կարող է հաջողել և ձախողվել նույն սեսիայում՝ կախված նրանից, թե պատասխանը եկել է քեշից, թե թարմ հարցումից։
| What you tested | What it proves |
|---|---|
Portal page or GetCapabilities | HTTP reachability to GeoServer only |
| A tile served from cache | nothing about the database |
GetMap for an uncached layer | a datastore query had to happen |
Գտեք այն քայլը, որն իսկապես ձախողվել է
Ծառայության մակարդակի մերժումը, պատկերի հարցումը, որը չի հասնում իր տվյալների պահոցին, և մեկ շերտի թույլտվության խնդիրը զննարկիչի ներդիրում նման են երևում, իսկ սերվերի մատյանում՝ բոլորովին այլ։ Պահանջեք կոնկրետ գործողությունը, ապա կարդացեք GeoServer-ի սեփական իրադարձությունը նույն ժամանակադրոշմի համար։
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"Երկրորդ հարցման 200-ը հավաստի պատկերով ապացուցում է, որ տվյալների պահոցը պատասխանել է։ 200-ը ծառայության բացառության փաստաթղթով ապացուցում է, որ չի պատասխանել, և բացառության տեքստը սովորաբար նշում է պահոցը, ոչ թե հաճախորդին։
Կարդացեք տվյալների պահոցը սերվերի կողմից
GeoServer-ի PostGIS տեղեկագիրքը թվարկում է, թե ինչ է պետք պահոցին՝ հոսթ, պորտ, տվյալների բազա և հավատարմագրեր։ Այս ամենը նկարագրում է այն միացումը, որը բացում է GeoServer-ը։ Դրանից ոչինչ չի նկարագրում սեղանադիր հաճախորդի մուտքը։ Այս չորս դաշտերը կարդացեք որպես սերվերի ցանցային համատեքստի մասին պնդում, և «նրանց մոտ աշխատում է» տոմսերի ամբողջ դասը դառնում է լուծելի։
Այդ պատճառով localhost տվյալների պահոցում այդքան տարածված սխալ է։ Դա նշանակում է հենց GeoServer գործընթացի ցանցային համատեքստը։ Եթե GeoServer-ը աշխատում է Docker-ում, մինչ PostGIS-ը աշխատում է հոսթում, localhost ցույց է տալիս կոնտեյների ներսը և ոչինչ չի գտնում, և ոչ մի VPN կարգավորում դա չի փոխում։
Սերվերի վրա ստուգեք երթուղին, լսիչը և նույնականացման քաղաքականությունը այդ հերթականությամբ։ PostgreSQL-ի հոսթի վրա հիմնված նույնականացումը համեմատում է իր տեսած աղբյուրի հասցեն, որը դարպասը կարող է թարգմանել, ուստի HBA ֆայլում հաճախորդի VPN լողավազան ավելացնելը հազվադեպ է ուղղում սերվերի կողմի միացումը։ Փորձարկեք այնպես, ինչպես կաներ սերվերը՝ նույն հոսթ, նույն պորտ, նույն օգտատեր։ Եթե այդ թեստը հաջողվում է, մինչ GeoServer-ը դեռ ձախողվում է, տարբերությունը գործընթացի համատեքստում է, ոչ թե տվյալների բազայում։
ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'Լողավազանները և քեշերը պահպանում են վիճակը փոփոխությունների ընթացքում
Տվյալների պահոցի միացումների լողավազանները բաց են պահում սոկետները։ Թունելը, որը բարձրացել է լողավազանի ստեղծումից մեկ ժամ անց, պարտադիր չէ, որ լողավազանին նոր ուղի տա, և անգործ միացումը կարող է մնալ մեռած երթուղու վրա, մինչև վալիդացիան կամ ժամանակի սահմանը այն փակի։ Ստուգեք տեղադրված պահոցի վալիդացիայի կարգավորումները՝ վերականգնում ենթադրելու փոխարեն, և խուսափեք ամբողջ ծառայությունը վերսկսելու գայթակղությունից, մինչև չիմանաք, թե որ շերտն է ձախողվել։
Սալիկների քեշերը ստեղծում են այդ խնդրի հայելային պատկերը՝ նրանք կարող են ճիշտ տեսք ունեցող քարտեզ մատուցել տվյալների բազայի միացումը կտրվելուց շատ ավելի ուշ։ Քեշը դատարկելը՝ «տեսնելու՝ արդյոք օգնում է», ոչնչացնում է միակ ապացույցը, որը ձեզ կասեր, թե որ ուղին էր կենդանի։
Փոխանցեք երկու աղբյուրներն էլ նշելով
Արագ ուղղում ստացող նկարագրությունը նշում է երկու բան՝ հաճախորդի հարցումը, որը հասել է GeoServer-ին, և այն backend գործողությունը, որը GeoServer-ը չի կարողացել ավարտել։ Երկուսով ճիշտ սեփականատերը կարող է վերանորոգել ձախողված ուղին։ Միայն առաջինով բնական ուղղումը տվյալների բազան հրապարակայնորեն բացելն է, ինչը լուծում է տոմսը՝ ստեղծելով ավելի վատ խնդիր։
Նշեք շերտը, պատասխանի կոդը, սերվերի կողմի բացառությունը և այն կոնտեյները կամ հոսթը, որը ստեղծել է այն։ Դա չորս տող է, և դրանք ամբողջությամբ վերացնում են երկիմաստությունը։