Ошибка БД MySQL

Вопросы
Кто-то может подсказать почему может выпадать ошибка такого содержания:

SQL Error: MySQL server has gone away at /home/i/public_html/classes/modules/blog/mapper/Blog.mapper.class.php line 269
Array ( [code] => 2006 [message] => MySQL server has gone away [query] => SELECT b.blog_id	 FROM prefix_blog as b	 WHERE b.blog_type<>'personal'	 [context] => /home/i/public_html/classes/modules/blog/mapper/Blog.mapper.class.php line 269 )


Раньше такой ошибки не было, в базу ни разу не залезал, ничего не менял с установки движка.

Ошибка выпадает рандомно: то сайт нормально работает, а вдруг может перестать вот с этой ошибкой.

Последний лог ошибок:

[2012-02-13 13:35:27][23327][8560][ERROR][SQL Error: MySQL server has gone away at /home/i/public_html/plugins/aceadminpanel/classes/modules/admin/mapper/Admin.mapper.class.php line 32
Array
(
    [code] => 2006
    [message] => MySQL server has gone away
    [query] => SELECT adminset_val FROM prefix_adminset WHERE adminset_key = 'version' 
    [context] => /home/i/public_html/plugins/aceadminpanel/classes/modules/admin/mapper/Admin.mapper.class.php line 32
)
]
[2012-02-13 13:35:27][23327][8560][ERROR][SQL Error: MySQL server has gone away at /home/i/public_html/plugins/aceadminpanel/classes/modules/admin/mapper/Admin.mapper.class.php line 222
Array
(
    [code] => 2006
    [message] => MySQL server has gone away
    [query] => SELECT
                u.*,
  		IF(ua.user_id IS NULL,0,1) as user_is_administrator,
                ab.banline, ab.banunlim, ab.bancomment, ab.banactive,
		INET_ATON('89.192.113.14') as ipn
            FROM
                prefix_user as u
            LEFT JOIN prefix_user_administrator AS ua ON u.user_id=ua.user_id
            LEFT JOIN prefix_adminban AS ab ON u.user_id=ab.user_id
            WHERE
                u.user_id = '1' 
    [context] => /home/i/public_html/plugins/aceadminpanel/classes/modules/admin/mapper/Admin.mapper.class.php line 222
)
]
[2012-02-13 13:35:27][23327][8560][ERROR][SQL Error: MySQL server has gone away at /home/i/public_html/classes/modules/blog/mapper/Blog.mapper.class.php line 269
Array
(
    [code] => 2006
    [message] => MySQL server has gone away
    [query] => SELECT 
			b.blog_id			 
			FROM 
				prefix_blog as b				
			WHERE 				
				b.blog_type<>'personal'				
				
    [context] => /home/i/public_html/classes/modules/blog/mapper/Blog.mapper.class.php line 269
)
]


UPD:
В поддержке хостинга написали:

Судя по всему время от времени скрипт почему то подвисает и срабатывает
таймаут mysql. Для решения проблемы надо прописать в скриптах после
подключения что то вроде:
mysql_query('SET SESSION wait_timeout = 60', $connection);

это должно решить проблему.

Куда именно необходимо вписать этот код — вот в этом остался основной теперь вопрос.
  • avatar
  • 1
  • 0
    • 0
    • 0
    • 3

10 комментариев

avatar
шаред или VPS?
avatar
шаред
avatar
Тогда ответ будет таким — mysql у вас перегружается и отваливается по вине соседних сайтов. Выставлять длинные таймауты — значит приговорить к тормозам и подвисаниям собственный сайт. Меняйте хостинг.

Если всё-таки есть непреодолимое желание выставить длинный таймаут (хотя это равносильно лечению температуры переразметкой градусника) — надо править engine\modules\database\Database.class.php
Там в районе 45 строки есть функция GetConnect, после строк

/**
	     	 * Устанавливаем настройки соединения, по хорошему этого здесь не должно быть :)
	     	 * считайте это костылём
	     	 */
        	$oDbSimple->query("set character_set_client='utf8', character_set_results='utf8', collation_connection='utf8_bin' ");


дописываем еще один костыль

$oDbSimple->query("SET SESSION wait_timeout = 60");


(не проверял, но должно работать)
avatar
параметр SESSION кстати не обязателен он для SET по умолчанию идет
avatar
как ни странно, но этот хостинг проработал нормально почти 8 месяцев, только сейчас начались вот подобные проблемы…
а хостинг то вроде очень даже неплохой был — sweb.
спасибо за все ответы, буду искать чего получше и постабильнее.
avatar
Видимо бд разрослась и поиск происходит значительно дольше чем по умолчанию установлен таймаут.
Я выставлял таймаут когда у меня между двумя запросами идет парсинг или какая нибудь длительная работа с данными.
avatar
Да особо некуда разрастаться то: 210 человек, 25 блогов, 244 топика. Разве это много?
avatar
Ну тогда разве что операции какие то долго выполняются между запросами, за время которых соединение успевает «отмереть»
avatar
Если кроме плагинов ничего нет, значит дело именно в них, а именно в тех, которые обращаются к БД? Или же им не обязательно обращаться к БД, чтобы тормозить процесс?
avatar
Совсем не обязательно. Скорее даже те плагины которые работаю с бд учитывая такое количество данных бд просто не могут так долго работать. А вот типо парсеров да, других примеров придумать не могу.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.