Oracle-ի սեսիան կտրվե՞լ է VPN-ով. ստուգեք keepalive շերտերը

Քսանհինգ րոպե օգտակար աշխատանք տվյալների բազայի հետ գրեթե ոչ մի ելք չի տալիս, և ուղու յուրաքանչյուր սարքից այդ հոսքը անգործուն է թվում։ Հենց անգործուն վիճակն է, որ հավաքվում է։ Դրանից հետո զեկույցը միշտ նույն ձևն ունի՝ հարցումը ընթանում էր, հետո սեսիան անհետացավ, և արդյունքը երբեք չհասավ։

Չորս ստուգում որոշում են՝ հանգիստ սեսիան գոյատևո՞ւմ է, և դրանք գնում են socket-ից դեպի դուրս։ Կատարեք դրանք հերթով, որովհետև յուրաքանչյուրը ենթադրում է, որ նախորդ շերտն անում է իր աշխատանքը։

Որ հոսքն է լռում

Կարևոր կապը այն է, որը տեղափոխում է տվյալների բազայի երթևեկությունը՝ ճանաչելի իր իսկ հասցեներով և պորտերով։ Ուրիշ ոչինչ այն չի թարմացնում։ Դարպասին ուղարկված ping-ը, նույն հոսթից երկրորդ SQL կապը և թունելի սեփական զարկերակը առանձին հոսքեր են՝ առանձին վիճակով յուրաքանչյուր սարքում, որը հետևում է դրանց։

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

Socket-ների ցանկը ցույց է տալիս կենդանի կապի ժամաչափերն ու հերթի վիճակը, ինչն ավելի տեղեկատվական է, քան հասանելիության թեստը։ sysctl արժեքները միջուկի լռելյայն արժեքներն են keepalive վարքագծի համար, և հաջորդ բաժինը բացատրում է, թե ինչու դրանք կարող են երբեք չկիրառվել ձեր սեսիայի վրա։ Լռելյայն արժեքը, որը երբեք չի գործարկվում, չի տարբերվում ընդհանրապես լռելյայն արժեք չունենալուց։

Գրի առեք հասցեները, պորտերը և ինտերֆեյսը, որոնք օգտագործում է կապը։ Երբ սեսիան մահանում է, հենց այդ մանրամասներն են թույլ տալիս ճիշտ սարքից հարցնել, թե ինչ է այն արել, փոխանակ հարցնելու, թե արդյոք ցանցը աշխատում էր։

Անգործության քաղաքականությունը լրանում է, թե սահմանափակում

Երկու քաղաքականություն առաջացնում են նույն ախտանիշը և պահանջում հակառակ արձագանք։ Անգործության ժամկետը հեռացնում է վիճակ, որը որակավորված երթևեկությունը կարող էր թարմացրել, և keepalive-ը կարող է դա կանխել։ Բացարձակ սեսիայի սահմանը հեռացնում է հոսքը ֆիքսված տևողությունից հետո՝ անկախ ակտիվությունից, և ոչ մի keepalive դա չի փոխում։

Հարցրեք յուրաքանչյուր միջնորդի տիրոջը, թե որն է նա իրականացնում։ Հրդեհապատը, NAT սարքը, բեռնվածքի հավասարակշռիչը և ամպային դարպասը բոլորը կարող են վիճակ պահել, և նրանք պարտավոր չեն համաձայնել։ Ամենանեղը սահմանում է այն ժամկետը, որը պետք է հաղթահարեք։

Այս տարբերությունը նաև ասում է, թե երբ դադարեցնել կարգաբերումը։ Եթե քաղաքականությունը բացարձակ սահման է, ճիշտ լուծումը ավելի կարճ աշխատանքային միավորն է, շարունակելի աշխատանքը կամ հաստատված բացառությունը, և ներքևի ստուգումը միայն կհաստատի, որ keepalive-ները ոչինչ չեն փոխել։

Socket-ի անջատիչը Linux-ի լռելյայն արժեքների հետևում

Keepalive-ը ընտրովի է յուրաքանչյուր socket-ի համար։ Միջուկի լռելյայն արժեքները նկարագրում են, թե ինչպես են զոնդերը վարվում այն բանից հետո, երբ socket-ը միացրել է մեխանիզմը, և դրանք այն չեն միացնում գոյություն ունեցող կապերի համար։ Ծրագիրը, որը երբեք չի խնդրում դա, ոչ մի զոնդ չի ստանում, ինչ էլ որ ասեն sysctl արժեքները։

Այդ պատճառով միայն թվերի բարձրացումը ոչինչ չի փոխում տվյալների բազայի հաճախորդի համար։ Մեխանիզմը պետք է միացնի հաճախորդի գրադարանը կամ ծրագիրը, և որտեղ ստեկը տալիս է կապի մակարդակի կառավարում, սահմանափակ կարգավորումը գերազանցում է ամբողջ հոսթի փոփոխությանը, որը ազդում է չկապված ծառայությունների վրա։

Առաջին զոնդին ընդառաջ ինտերվալը նույնպես հարցման ժամկետ չէ։ Առողջ կապը լռում է զոնդերի միջև, և մեռած գործընկերը ճանաչվում է ըստ զոնդի ինտերվալի և քանակի։ Այս երեք արժեքները որպես մեկ ժամկետ կարդալը հանգեցնում է կարգավորումների, որոնք խափանումը հայտնաբերում են կա՛մ շատ ուշ, կա՛մ շատ շտապ։ Դրանք կառավարում են հայտնաբերումը, ոչ թե ծրագրի համբերությունը։

EXPIRE_TIME-ը տվյալների բազայի կարգավորում է, ոչ ցանցային ուղղում

Oracle Net-ն առաջարկում է իր սեփական կենսունակության մեխանիզմը, կարգավորված գործընթացի արդյունավետ պրոֆիլում, այլ ոչ պատահական ֆայլում, որի անունը նման է։ Արժեքն արտահայտվում է րոպեներով։

SQLNET.EXPIRE_TIME = 5

Նրա հիմնական նպատակը սերվերի կողմում մեռած կապերի հայտնաբերումն է, և ընդլայնված մոդելը աջակցող հարթակներում այն նաև կարգավորում է TCP keepalive-ի վարքագիծը այդ կապերի համար։ Սա օգտակար հատկություն է. տվյալների բազայի շերտը կարող է զոնդեր կազմակերպել՝ չպահանջելով, որ հաճախորդ ծրագիրը փոխվի։

Վերևի օրինակելի արժեքը ենթադրվող ժամկետի դեմ համաձայնեցված ընտրություն է, ոչ թե առաջարկություն։ Փաստաթղթավորված ընդհանուր ուղեցույցը ավելի երկար ինտերվալ է, և ճիշտ թիվը կախված է տեղադրված իրականացումից, ընդունելի զոնդի ծախսից և ուղու իրական թարմացման կանոններից։ Տեղադրեք կարգավորումը այն պրոֆիլում, որը կարդում է համապատասխան գործընթացը, և հաստատեք, որ գործընթացը վերցրել է այն։ Oracle-ը փաստաթղթավորում է պրոֆիլների տեղերը և հայտնաբերման վարքագիծը իր պարամետրերի տեղեկագրում։

Փորձեք հանգիստ ինտերվալը, ապա պլանավորեք վերականգնումը

Թողեք նոր թույլատրված կապն անցնի հանգիստ ժամանակահատվածով, որն ավելի երկար է, քան այն ժամկետը, որը փորձում եք հաղթահարել, և դիտեք կենսունակության երթևեկությունը և ծրագրի արդյունքը։ Մի գրավեք օգտակար բեռի բովանդակություն, որ ձեզ պետք չէ. ժամաչափերն ու կապի վիճակը պատասխանում են հարցին։

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

Եթե սեսիան դեռ անհետանում է, ժամկետը պատկանում է սարքի, որին դեռ չեք հարցրել, կամ քաղաքականությունը բացարձակ սահման է։ Եթե այն գոյատևում է, նշեք, թե որ շերտը փոխվեց, որպեսզի հաջորդ հանգիստ գործողությունը չկրկնի հետաքննությունը։

Վերջապես որոշեք, թե ինչ է լինում, երբ կապն իսկապես ընկնում է, որովհետև կենսունակության ստուգումները նվազեցնում են հաճախականությունը և երբեք չեն վերացնում հնարավորությունը։ Հաստատեք տվյալների բազայի գործողության գրանցված արդյունքը նախքան այն նորից ուղարկելը. պատասխանի կորուստը ոչինչ չի ապացուցում այն մասին, թե արդյոք աշխատանքը հաստատվել է։ Ամեն ինչի համար, ինչ պետք է գոյատևի նոութբուքի փակումից կամ թունելի վերսկսումից, սերվերին պատկանող աշխատանքը՝ դիմացկուն արդյունքով, ավելի ամուր ձևավորում է, և keepalive-ը պլանավորիչ չէ։