Вопрос или проблема
У нас есть пул соединений JDBC на сервере WebLogic 12c. Когда резервная база данных уходит в офлайн, пул переходит в состояние приостановки, и когда база данных снова становится доступной через короткий промежуток времени (скажем, 5 минут), пул возвращается в рабочее состояние. Это нормально и именно так я ожидал, что будет вести себя WebLogic.
Но пару дней назад база данных упала на примерно 30 минут, и когда она снова стала доступной, пул постоянно остается в состоянии приостановки и никогда не возвращается в рабочее состояние. Нам нужно вручную перезапускать пул. Есть ли какие-то настройки, которые могут изменить это поведение? Наша частота проверки составляет 600 секунд, а частота повторного создания соединения — 0.
Как долго вы на самом деле ждете? Ваша конфигурация означает, что вам может потребоваться ждать до 10 минут, так как частота проверки установлена на 600 секунд (10 минут).
Частота повторного создания соединений относится к сценарию, в котором вы перезапустили WebLogic во время сбоя БД (или возникли другие проблемы с подключением к БД), и источник данных не был создан во время запуска. Этот параметр указывает WebLogic, с какой частотой он будет повторять попытки создания соединения. С вашей конфигурацией источник данных действительно останется неактивным навсегда, но он не будет в состоянии приостановки, он даже не отобразится на вкладке мониторинга, так как не был инициализирован. И ваш управляемый сервер запустится в режиме администратора.
Я лично предпочитаю устанавливать этот параметр на значение > 0 во всех своих источниках данных. В моем стандартном скрипте wlst я устанавливаю его на 300 секунд (5 минут).
Ответ или решение
Ситуация, с которой вы столкнулись, действительно требует внимательного подхода к настройкам пула JDBC соединений в WebLogic. Давайте разберемся с причиной, по которой пул соединений продолжает оставаться в состоянии "подвешенного" после восстановления связи с базой данных.
Возможные причины и решения
-
Настройки проверки соединений: Поскольку вы указали, что частота тестирования соединений составляет 600 секунд (10 минут), это может быть одной из причин, почему пул остается в состоянии "подвешенном" после долгого простоя базы данных. Вы можете рассмотреть возможность уменьшения этого параметра, чтобы WebLogic чаще проверял доступность базы данных. Например, вы можете установить его на 300 секунд или даже меньше.
-
Частота повторных попыток создания соединения: Вы упомянули, что частота повторных попыток создания соединения равна 0. Это означает, что в случае возникновения ошибки WebLogic не будет пытаться повторно установить соединение. Рекомендуется установить это значение на большее число, например, 300 секунд. Это даст ему возможность пытаться восстановить состояние соединений.
-
Проверка состояния соединений: Убедитесь, что в настройках пула установлены подходящие параметры для проверки состояния соединений (например,
Connection Test Table,Test Connections on Reserve,Test Connections on Create). Эти параметры помогут WebLogic автоматически проверять и восстанавливать соединения. -
Логи и мониторинг: Включите детальное логирование соединений, чтобы понять, что происходит, когда база данных восстанавливается после длительного простоя. Логи могут помочь выявить ошибки, которые происходят в момент, когда WebLogic пытается восстановить соединения.
-
Обновление WebLogic: Убедитесь, что вы используете последнюю версию WebLogic с установленными патчами, так как в старых версиях могут быть баги, касающиеся управления состоянием соединений.
Подразумеваемые шаги
- Уменьшите
Test Frequencyдо 300 секунд. - Установите
Connection Creation Retry Frequencyна 300 секунд или на более короткий промежуток времени, чтобы обеспечить автоматическое восстановление соединений. - Проверьте и настройте параметры проверки состояния соединений.
- Исключите возможные проблемы в логах, которые могут предшествовать уходу пула в состояние "подвешенного".
Заключение
С помощью этих изменений вы сможете оптимизировать работу вашего JDBC пула и улучшить его реакцию на восстановление базы данных. Если вы выполните предложенные рекомендации, это должно помочь избежать необходимости ручной перезагрузки пула в будущем.