Переподключение 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 - снизил, убедился что все работает и поднял значение.

[Ипатьев]

Владимир Егудин, хороший вариант. Но чисто для информации, на будущее:
собаку надо убрать, она тут явно ни к селу ни к городу
ловить лучше \mysqli_sql_exception
вместо die должно быть throw $e;
ну и подготовленные запросы надо потихоньку осваивать

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

• касательно собаки - абсолютно верно, не обратил внимания
  
• почему лучше ловить \mysqli_sql_exception в чем выигрыш?
  
• насчет die - полностью согласен - при тестировании мне так было удобнее
  
• насчет подготовленных запросов - не понял как они связаны с переподключением?
  

Относительно подготовленных запросов:
1. можно код писать используя лишь query, используя следующие запросы:
PREPARE stmt FROM 'SELECT ....
SET @a = ...
SET @b = ...
EXECUTE stmt.....
2. Соглашусь, что в рамках демона, подготовленные запросы имеют смысл, так как одни и те же запросы исполняются многократно, бывают еще различные обработчики, парсеры, которые в циклах что либо выполняют при этом можно получить оптимизацию нагрузки на сервер. И да, при переподключении если пакет собран без флага MYSQLI_NO_CHANGE_USER_ON_PCONNECT то PREPARE нужно выполнять повторно, об этом функционале я сейчас и думаю. Но это исключительно частные случаи.
Стандартный сайт, да и большая часть любого правильно написанного кода одни и те же запросы исполняет 1-2 раза. Если сравнить стоимость одного query и стоимость prepare, set и execute то второй подход будет дороже. Если же вы относительно защиты от sql-инъекций - то она реализована на другом уровне.

[Ипатьев]

Владимир Егудин, в данном случае выигрыша нет, но просто порядок должен быть. если хотим поймать только исключение mysqli, то и его надо ловить.
"при тестировании мне так было удобнее" - это глупость какая-то. throw $e; делает ровно то же самое, плюс выводит больше полезной информации, которая и нужна при тестировании. Ну и в целом непонятно, зачем писать две версии кода, одну для тестирования, а вторую для прода.

можно код писать используя лишь query, используя следующие запросы:
PREPARE stmt FROM 'SELECT ....

Можно, но не нужно.

же вы относительно защиты от sql-инъекций - то она реализована на другом уровне.

Ну в теории это конечно возможно. Но на практике обычно такая реализация наполовину состоит из суеверий а наполовину - из супер-современных мануалов конца прошлого века. И дырявая на все стороны.

Впрочем, если уж используется "защита на другом уровне" и демон, то сам бог велел сделать пул подключений и использовать асинхронные запросы.

Answer 2

[Vitsliputsli]

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

Comments

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

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

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

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

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

[Vitsliputsli]

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

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

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