Oracle-istunto katkesi VPN:n yli? Tarkista keepalive-kerrokset

Kaksikymmentäviisi minuuttia hyödyllistä tietokantatyötä tuottaa tuskin mitään tulostetta, ja jokaisesta reitin laitteesta se virtaus näyttää passiiviselta. Passiivinen tila on juuri se, mikä kerätään. Jälkikäteen tehty raportti on aina samanmuotoinen: kysely oli käynnissä, sitten istunto katosi, eikä tulosta koskaan saapunut.

Neljä tarkistusta ratkaisee, selviääkö hiljainen istunto, ja ne etenevät socketista ulospäin. Tee ne järjestyksessä, sillä jokainen olettaa edellisen kerroksen hoitavan tehtävänsä.

Mikä virtaus muuttuu hiljaiseksi

Ratkaiseva yhteys on se, joka kuljettaa tietokantaliikennettä, tunnistettuna omista osoitteistaan ja porteistaan. Mikään muu ei virkistä sitä. Ping yhdyskäytävälle, toinen SQL-yhteys samalta isännältä ja tunnelin oma sydämenlyönti ovat erillisiä virtauksia, joilla on erillinen tila jokaisessa niitä seuraavassa laitteessa.

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

Socket-luettelo näyttää elävän yhteyden ajastimet ja jonotilan, mikä kertoo enemmän kuin tavoitettavuustesti. sysctl-arvot ovat ytimen oletusarvoja keepalive-käyttäytymiselle, ja seuraava jakso selittää, miksi ne eivät ehkä koskaan päde istuntoosi. Oletusarvo, joka ei koskaan laukea, on mahdoton erottaa siitä, ettei oletusarvoa ole lainkaan.

Kirjoita muistiin osoitteet, portit ja liitäntä, jota yhteys käyttää. Kun istunto kuolee, juuri ne tiedot antavat sinun kysyä oikealta laitteelta, mitä se teki, sen sijaan että kysyisit, oliko verkko pystyssä.

Vanheneeko passiivisuuskäytäntö vai rajoittaako se

Kaksi käytäntöä tuottaa saman oireen ja vaatii vastakkaisia vastauksia. Passiivisuusaikakatkaisu poistaa tilan, jonka kelvollinen liikenne olisi voinut virkistää, ja keepalive voi estää sen. Ehdoton istuntoraja poistaa virtauksen kiinteän keston jälkeen aktiivisuudesta riippumatta, eikä mikään keepalive muuta sitä.

Kysy jokaisen välittäjän omistajalta, kumman se toteuttaa. Palomuuri, NAT-laite, kuormantasaaja ja pilviyhdyskäytävä voivat kaikki pitää tilaa, eikä niiden tarvitse olla samaa mieltä. Kapein asettaa määräajan, joka sinun on voitettava.

Tämä ero kertoo myös, milloin lopettaa säätäminen. Jos käytäntö on ehdoton raja, oikea ratkaisu on lyhyempi työyksikkö, uudelleen aloitettava työ tai hyväksytty poikkeus, ja alla oleva tarkistus vain vahvistaa, etteivät keepalivet muuttaneet mitään.

Linuxin oletusarvojen takana oleva socket-kytkin

Keepalive on socketikohtainen valinta. Ytimen oletusarvot kuvaavat, miten testausviestit käyttäytyvät, kun socket on jo ottanut mekanismin käyttöön, eivätkä ne ota sitä käyttöön olemassa oleville yhteyksille. Sovellus, joka ei koskaan pyydä sitä, ei saa testausviestejä, mitä sysctl-arvot sanovatkaan.

Siksi pelkkä lukujen suurentaminen ei muuta mitään tietokanta-asiakkaalle. Asiakaskirjaston tai sovelluksen on otettava mekanismi käyttöön, ja kun pino tarjoaa yhteyksikohtaisia säätimiä, rajattu asetus voittaa koko isäntää koskevan muutoksen, joka vaikuttaa asiaankuulumattomiin palveluihin.

Ensimmäisen testausviestin väli ei ole kyselyaikakatkaisu sekään. Terve yhteys pysyy hiljaisena testausviestien välillä, ja kuollut vastapuoli tunnistetaan testausvälin ja -määrän mukaan. Näiden kolmen arvon lukeminen yhtenä aikakatkaisuna johtaa asetuksiin, jotka havaitsevat vian joko aivan liian myöhään tai aivan liian innokkaasti. Ne ohjaavat havaitsemista, eivät sovelluksen kärsivällisyyttä.

EXPIRE_TIME on tietokanta-asetus, ei verkkokorjaus

Oracle Net tarjoaa oman eloisuusmekanisminsa, joka määritetään prosessin tehokkaassa profiilissa eikä mielivaltaisessa tiedostossa, jolla sattuu olemaan samankaltainen nimi. Arvo ilmaistaan minuutteina.

SQLNET.EXPIRE_TIME = 5

Sen pääasiallinen tarkoitus on palvelinpuolinen kuolleiden yhteyksien havaitseminen, ja parannettua mallia tukevilla alustoilla se säätää myös näiden yhteyksien TCP-keepalive-käyttäytymistä. Se on hyödyllinen ominaisuus: tietokantakerros voi järjestää testausviestit pyytämättä asiakassovellusta muuttumaan.

Yllä oleva havainnollinen arvo on koordinoitu valinta oletettua määräaikaa vastaan, ei suositus. Dokumentoitu yleinen ohje on pidempi väli, ja oikea luku riippuu asennetusta toteutuksesta, hyväksymästäsi testausviestien kuormituksesta ja reitin todellisista virkistyssäännöistä. Aseta arvo profiiliin, jota kyseinen prosessi lukee, ja varmista, että prosessi on ottanut sen käyttöön. Oracle dokumentoi profiilin sijainnit ja havaitsemiskäyttäytymisen parametriviitteessään.

Testaa hiljainen jakso ja suunnittele sitten palautuminen

Anna uuden sallitun yhteyden kulkea hiljaisen jakson läpi, joka on pidempi kuin määräaika, jonka yrität voittaa, ja seuraa eloisuusliikennettä ja sovelluksen tulosta. Älä kaappaa hyötykuorman sisältöä, jota et tarvitse; ajastimet ja yhteyden tila vastaavat kysymykseen.

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

Jos istunto yhä katoaa, määräaika kuuluu laitteelle, jolta et ole vielä kysynyt, tai käytäntö on ehdoton raja. Jos se selviää, kirjaa, mikä kerros muuttui, jotta seuraava hiljainen toimenpide ei toista tutkimusta.

Päätä lopuksi, mitä tapahtuu, kun yhteys todella katkeaa, sillä eloisuustarkistukset vähentävät tiheyttä eivätkä koskaan poista mahdollisuutta. Selvitä tietokantatoimenpiteen kirjattu tulos ennen sen lähettämistä uudelleen: vastauksen menettäminen ei todista mitään siitä, vahvistettiinko työ. Kaikelle, jonka on kestettävä kannettavan sulkeminen tai tunnelin uudelleenkäynnistys, palvelimen omistama työ, jolla on kestävä tulos, on vahvempi suunnittelu, eikä keepalive ole ajastin.