Oracle-økt droppet over VPN? Sjekk keepalive-lagene

Tjuefem minutter med nyttig databasearbeid gir nesten ingen utdata, og fra hver enhet på veien ser den strømmen inaktiv ut. Inaktiv tilstand er nettopp det som blir samlet opp. Rapporten etterpå har alltid samme form: spørringen kjørte, så forsvant økten, og resultatet kom aldri fram.

Fire kontroller avgjør om en stille økt overlever, og de går fra socketen og utover. Gjør dem i rekkefølge, for hver av dem forutsetter at laget før gjør jobben sin.

Hvilken strøm blir stille

Forbindelsen som betyr noe, er den som bærer databasetrafikken, identifisert av sine egne adresser og porter. Ingenting annet fornyer den. En ping til en gateway, en annen SQL-forbindelse fra samme vert og tunnelens egen hjerteslag er separate strømmer med separat tilstand på hver enhet som følger dem.

ss -tio dst 10.60.4.20
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes

Socket-oversikten viser timere og køtilstand for den levende forbindelsen, noe som er mer informativt enn en nåbarhetstest. sysctl-verdiene er kjernens standardverdier for keepalive-atferd, og neste avsnitt forklarer hvorfor de kanskje aldri gjelder for økten din. En standardverdi som aldri utløses, kan ikke skilles fra ingen standardverdi i det hele tatt.

Skriv ned adressene, portene og grensesnittet forbindelsen bruker. Når en økt dør, er det disse detaljene som lar deg spørre riktig enhet hva den gjorde, i stedet for å spørre om nettverket var oppe.

Om inaktivitetsregelen utløper eller begrenser

To regler gir samme symptom og krever motsatte svar. En inaktivitets-timeout fjerner tilstand som kvalifiserende trafikk kunne ha fornyet, og en keepalive kan forhindre det. En absolutt øktgrense fjerner strømmen etter en fast varighet uansett aktivitet, og ingen keepalive endrer det.

Spør eieren av hver mellomliggende enhet hvilken av de to den implementerer. En brannmur, en NAT-enhet, en lastbalanserer og en skygateway kan alle holde tilstand, og de trenger ikke være enige. Den sneverste setter fristen du må slå.

Den forskjellen forteller deg også når du skal slutte å justere. Hvis regelen er en absolutt grense, er riktig løsning en kortere arbeidsenhet, en jobb som kan gjenopptas, eller et godkjent unntak, og kontrollen nedenfor bekrefter da bare at keepalives ikke gjorde noen forskjell.

Socket-bryteren bak Linux-standardverdiene

Keepalive er valgfritt per socket. Kjernens standardverdier beskriver hvordan prober oppfører seg når en socket først har aktivert mekanismen, og de aktiverer den ikke for eksisterende forbindelser. Et program som aldri ber om det, får ingen prober, uansett hva sysctl-verdiene sier.

Derfor endrer det ingenting for en databaseklient å øke tallene alene. Klientbiblioteket eller programmet må aktivere mekanismen, og der stakken tilbyr styring per forbindelse, vinner en avgrenset innstilling over en endring for hele verten som påvirker urelaterte tjenester.

Intervallet til første probe er heller ikke en spørringstimeout. En frisk forbindelse er stille mellom probene, og en død peer gjenkjennes etter probeintervall og antall. Å lese de tre verdiene som én timeout er hvordan folk ender med innstillinger som oppdager feilen enten altfor sent eller altfor ivrig. De styrer oppdagelsen, ikke programmets tålmodighet.

EXPIRE_TIME er en databaseinnstilling, ikke en nettverksfiks

Oracle Net tilbyr sin egen livlighetsmekanisme, konfigurert i den effektive profilen for prosessen og ikke i en vilkårlig fil som tilfeldigvis har et lignende navn. Verdien uttrykkes i minutter.

SQLNET.EXPIRE_TIME = 5

Hovedformålet er serversidig oppdagelse av døde forbindelser, og på plattformer som støtter den forbedrede modellen justerer den også TCP keepalive-atferd for disse forbindelsene. Det er en nyttig egenskap: databaselaget kan sørge for prober uten å be klientprogrammet endre seg.

Eksempelverdien over er et samordnet valg mot en antatt frist, ikke en anbefaling. Den dokumenterte generelle veiledningen er et lengre intervall, og det riktige tallet avhenger av den installerte implementasjonen, probe-overheaden du aksepterer og de faktiske fornyelsesreglene på veien. Sett innstillingen i profilen som den aktuelle prosessen leser, og bekreft at prosessen har tatt den opp. Oracle dokumenterer profilplasseringene og oppdagelsesatferden i sin parameterreferanse.

Test det stille intervallet, og planlegg deretter gjenoppretting

La en ny tillatt forbindelse gå gjennom en stille periode som er lengre enn fristen du prøver å slå, og følg med på livlighetstrafikken og programresultatet. Ikke fang nyttelastinnhold du ikke trenger; timere og forbindelsestilstand svarer på spørsmålet.

ss -tio dst 10.60.4.20
# after the quiet interval, same command
ls -l "$ORACLE_HOME/network/admin/sqlnet.ora"

Hvis økten fortsatt forsvinner, tilhører fristen en enhet du ennå ikke har spurt, eller regelen er en absolutt grense. Hvis den overlever, noter hvilket lag som ble endret, slik at neste stille operasjon ikke gjentar undersøkelsen.

Til slutt, bestem hva som skjer når forbindelsen faktisk faller, for livlighetskontroller reduserer frekvensen og fjerner aldri muligheten. Fastslå databaseoperasjonens registrerte utfall før du sender den på nytt: å miste svaret beviser ingenting om hvorvidt arbeidet ble bekreftet. For alt som må overleve at en laptop lukkes eller at en tunnel starter på nytt, er en servereid jobb med et varig resultat det sterkere designet, og en keepalive er ikke en planlegger.