Переподключение PHP к MySQL как правильно организовать?

Question

[Владимир Егудин]

Столкнулся со следующей проблемой, PHP-процесс постоянно висит в памяти, и периодически кидает запросы в БД.
Однако столкнулся с проблемой, что если нет внешней активности, то он не обращается к базе и та закрывает соединение.

Есть собственно механизм mysqli::ping - который проверяет соединение и восстанавливает подключение, если оно утрачено. Смотрю сейчас документацию (https://www.php.net/manual/ru/mysqli.configuration...) - а там жирным написано:

Внимание Функция УСТАРЕЛА с PHP 8.4.0. Пользоваться функцией настоятельно не рекомендуют.

окей, читаем дальше, есть глобальная настройка mysqli.reconnect, переходим к ней (https://www.php.net/manual/ru/mysqli.configuration...) и читаем такое:

Замечание: Эта настройка игнорируется драйвером "mysqlnd" и была удалена в PHP 8.2.0.

В итоге я не понимаю как верно организовать процесс подключения, чтоб он работал на любых версиях PHP - как 5.4, так и 8.4 и не вызывал проблем

Может кто-то сталкивался?

Comments

[Akina]

PHP-процесс постоянно висит в памяти, и периодически кидает запросы в БД.

Уточните временнЫе параметры этого "периодически". Если речь идёт об интервалах бездействия в несколько секунд (тем более минут), то гораздо более разумно устанавливать соединение в начале сеанса обмена, выполнять нужные операции, и сразу по окончании закрывать.

Answer 1

[Rsa97]

Ловить исключение, если ошибка 2006, то переподключаться и повторять запрос. Можно организовать в своём враппере поверх PDO или mysqli.
Менее универсальный способ - увеличить таймаут для сессии

SET session wait_timeout=28800
SET session interactive_timeout=28800

Comments

[Владимир Егудин]

Спасибо, реализовал именно как вы и посоветовали:

try {
	$result = parent::query($query);
} catch (\Exception $e) {
	$error_message = $e->getMessage();

	if (str_contains($error_message, 'gone away')) {
		parent::__construct($host, $user, $pass, $base, $port);
	
		$result = @parent::query($query);
	} else
		die('Error: ' . $error_message);
}

на время тестов wait_timeout - снизил, убедился что все работает и поднял значение.

Answer 2

[Vitsliputsli]

Самый правильный вариант - отключаться, если соединение не используется. Правильно, т.к. не используем ресурсы для поддержания ненужного соединения, ни на клиенте, ни на сервере. И не ловим эксепшены.
И только если ну никак нельзя это контролировать, тогда реконнект по эксепшену.

Comments

[Владимир Егудин]

В данном случае это демон для вебсокета - он работает постоянно. Пока есть клиенты - он активен и постоянно обращается к БД.
Настройка wait_timeout стоит на 8 часов ожидания плюс пока велась разработка он часто рестартовался.
Однако во время эксплуатации стало заметно что каждое утро вебсокет недоступен, перезапуск сервиса его воскрешает, однако следующим утром опять идентичная ситуация.

Стал курить логи и нашел "Mysql server gone away" и понял, что надо восстанавливать подключение. Однако трактование документации сначала запутало. Отсюда и данный вопрос.

Применительно к данной ситуации - отключение не хорошая практика, так как подключение очень дорогостоящая операция. Как следствие в какой момент отключаться и подключаться - не понятно.

Потому, я согласен, что лучше анализировать исключения и при необходимости подключаться заново.

[Vitsliputsli]

Владимир Егудин,

Применительно к данной ситуации - отключение не хорошая практика, так как подключение очень дорогостоящая операция. Как следствие в какой момент отключаться и подключаться - не понятно.

Подключение не бесплатное, но далеко не дорогостоющее, тем более для mysql. И я не предлагаю для каждого запроса делать коннект, а реконнект по эксепшену это ведь тоже коннект.
Отключаться нужно по неактивности, как выберете, хоть 10 минут, хоть 1 час. В вашей схеме, при асинхронности, это не должно быть проблемой.
Я не настаиваю, что только так нужно, но на мой взгляд вместо "словить" ошибку и среагировать лучше недопустить ошибку.