Жизненный цикл соединения: протухшие соединения и как их старить

Сервис работает нормально весь день, затем в 3 ночи — во время затишья трафика — первые утренние запросы падают с «connection reset by peer». Ничего не деплоили, база здорова. Случилось то, что за тихую ночь wait_timeout базы, правило простоя фаервола и балансировщик тихо сбросили долго-простаивавшие пулевые соединения, но пул не заметил. Он держал эти мёртвые сокеты и уверенно выдал один первому утреннему запросу, который записал запрос в закрытую трубу. Величайшая сила пула — держать соединения открытыми для переиспользования — это и обязательство: соединение, которое он держит, могло умереть, не сказав ему.

Удерживаемое соединение может умереть без ведома пула

Пул держит соединения открытыми именно затем, чтобы запросы пропускали рукопожатие — но «открыто на нашей стороне» не значит «живо из конца в конец». У TCP-соединения два конца и несколько middlebox-ов, любой из которых может снести его, пока сторона пула всё ещё выглядит ESTABLISHED:

• Сама база. Postgres и MySQL применяют лимиты простоя и времени жизни на стороне сервера (idle_in_transaction_session_timeout, MySQL wait_timeout по умолчанию 8 часов). Когда сервер закрывает backend, клиентский сокет не уведомляется, пока в него снова не запишут.
• Фаерволы и NAT-шлюзы. Stateful-фаерволы сбрасывают простаивающие потоки через несколько минут, чтобы вернуть место в таблице; типичный облачный NAT-таймаут простоя около 350 секунд. После него соединение — чёрная дыра, пакеты пропадают.
• Балансировщики и прокси. LB перед базой (или PgBouncer) имеет свои лимиты простоя и времени жизни и перерабатывает backend-ы на деплоях.

Итог: соединение, простаивающее в пуле, может быть тихо мёртвым, и пул узнаёт это лишь когда запрос пытается его использовать и получает reset или зависание.

Три контроля держат пул свежим

Хороший пул защищается от протухания тремя кооперирующими настройками:

• Max lifetime. Уволь и замени каждое соединение после фиксированного возраста (HikariCP maxLifetime, дефолт 30 минут) независимо от того, выглядит ли оно здоровым. Это проактивно ротирует соединения до того, как middlebox-ы или сервер их убьют. Важное правило: maxLifetime должен быть короче собственного таймаута соединения базы (напр. на несколько секунд под MySQL wait_timeout), чтобы пул всегда закрывал соединение до сервера.
• Idle timeout. Сжимай пул назад к минимуму в тихие периоды, вытесняя соединения, простаивающие дольше idleTimeout (дефолт 10 минут). Это делает что-то лишь если minimumIdle задан ниже максимума — иначе пул держит все соединения вечно.
• Keepalive / валидация. Периодически прощупывай простаивающие соединения (keepaliveTime) и/или тестируй соединение при взятии до выдачи. Современный пул валидирует лёгким пингом на уровне протокола; если он провалится, соединение тихо выбрасывается и создаётся свежее — поэтому запрос никогда не видит мёртвый сокет.

Валидируй в правильный момент, дёшево

У валидации есть цена: проверка на каждом взятии добавляет круговой обмен к каждому запросу, что может стереть выигрыш задержки, ради которого пул существует. Современный компромисс — валидировать при взятии, но пропускать проверку, если соединение использовалось совсем недавно — aliveBypassWindow HikariCP в 500 мс значит, что соединение, возвращённое и снова взятое в пределах полусекунды, доверяется без прощупывания, по рассуждению, что оно не могло протухнуть так быстро. Это держит горячие соединения быстрыми, всё ещё ловя те, что простояли достаточно долго, чтобы быть под риском.