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 |
യഥാർത്ഥത്തിൽ പരാജയപ്പെട്ട ഘട്ടം കണ്ടെത്തുക
സേവന തലത്തിലുള്ള നിരസനം, സ്വന്തം ഡാറ്റാ സ്റ്റോറിൽ എത്താത്ത ഇമേജ് അഭ്യർത്ഥന, ഒരു ലേയറിലെ അനുമതി പ്രശ്നം എന്നിവ ബ്രൗസർ ടാബിൽ ഒരുപോലെ തോന്നും, സർവർ ലോഗിൽ തികച്ചും വ്യത്യസ്തവുമാകും. കൃത്യമായ പ്രവർത്തനം ആവശ്യപ്പെടുക, തുടർന്ന് അതേ സമയ മുദ്രയ്ക്കുള്ള സർവറിന്റെ സ്വന്തം ഇവന്റ് വായിക്കുക.
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-ൽ എത്തിയ ക്ലയന്റ് അഭ്യർത്ഥന, ഒപ്പം GeoServer പൂർത്തിയാക്കാൻ കഴിയാത്ത ബാക്ക്എൻഡ് പ്രവർത്തനം. രണ്ടും ഉണ്ടെങ്കിൽ ശരിയായ ഉടമയ്ക്ക് പരാജയപ്പെട്ട പാത നന്നാക്കാം. ആദ്യത്തേത് മാത്രമുണ്ടെങ്കിൽ സ്വാഭാവിക പരിഹാരം ഡാറ്റാബേസ് പൊതുവായി തുറക്കുക എന്നതാണ്, അത് ടിക്കറ്റ് മോശമായ ഒരു പ്രശ്നം സൃഷ്ടിച്ച് പരിഹരിക്കുന്നു.
ലേയർ, പ്രതികരണ കോഡ്, സർവർ ഭാഗത്തെ ഒഴിവാക്കൽ, അത് നിർമ്മിച്ച കണ്ടെയ്നർ അല്ലെങ്കിൽ ഹോസ്റ്റ് എന്നിവ കുറിച്ചുവയ്ക്കുക. അവ നാല് വരികളാണ്, അവ അവ്യക്തത പൂർണമായി ഒഴിവാക്കുന്നു.