Сеанс Oracle обірвався через VPN? Перевірте рівні keepalive

Двадцять п’ять хвилин корисної роботи з базою даних майже не дають виводу, і з погляду кожного пристрою на шляху цей потік виглядає неактивним. Саме неактивний стан і збирається. Звіт потім завжди має одну форму: запит виконувався, далі сеанс зник, а результат так і не надійшов.

Чотири перевірки вирішують, чи виживе тихий сеанс, і вони йдуть від сокета назовні. Робіть їх по порядку, бо кожна припускає, що попередній рівень виконує свою роботу.

Який потік затихає

Важливе з’єднання, яке несе трафік бази даних, визначене власними адресами й портами. Ніщо інше його не освіжає. 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

Список сокетів показує таймери й стан черги для живого з’єднання, що інформативніше за перевірку доступності. Значення sysctl — це усталені значення ядра для поведінки keepalive, і наступний розділ пояснює, чому вони можуть ніколи не застосуватися до вашого сеансу. Усталене значення, яке ніколи не спрацьовує, не відрізнити від повної відсутності усталеного значення.

Запишіть адреси, порти й інтерфейс, які використовує з’єднання. Коли сеанс помирає, саме ці деталі дають змогу запитати потрібний пристрій, що він зробив, замість питання, чи була мережа доступна.

Чи спливає політика простою, чи обмежує

Дві політики дають однаковий симптом і вимагають протилежних дій. Тайм-аут простою видаляє стан, який кваліфікований трафік міг би оновити, і keepalive може це запобігти. Абсолютний ліміт сеансу видаляє потік після фіксованої тривалості незалежно від активності, і жоден keepalive цього не змінить.

Запитайте власника кожного посередника, яку з двох він реалізує. Міжмережевий екран, пристрій NAT, балансувальник навантаження й хмарний шлюз можуть зберігати стан, і їм не обов’язково збігатися. Найвужчий задає строк, який треба перемогти.

Ця різниця також підказує, коли припинити налаштування. Якщо політика — абсолютний ліміт, правильне рішення — коротша одиниця роботи, відновлювана задача або схвалений виняток, і перевірка нижче лише підтвердить, що keepalive нічого не змінили.

Перемикач сокета за усталеними значеннями Linux

Keepalive вмикається окремо для кожного сокета. Усталені значення ядра описують, як поводяться проби після того, як сокет увімкнув механізм, і самі вони його для наявних з’єднань не вмикають. Застосунок, який ніколи його не просить, не отримує проб, хоч би що казали значення 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 не планувальник.