MySQL 5.5 - потеря соединения с сервером MySQL во время запроса

У меня есть сервер Ubuntu 12.04 LTS, работающий на немецком хостере (виртуализированная система).

# uname -a 
Linux ... 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Я хочу перенести систему Web CMS, которая называется Contao . Это не моя первая миграция, но моя первая миграция с проблемами соединения с mysql.

Миграция прошла успешно, у меня работает та же версия Contao (это более или менее просто копирование / вставка).

Для базы данных я сделал:

apt-get install mysql-server phpmyadmin

Я установил пароль root и добавил пользователя для CMS, который имеет достаточно прав на свою собственную базу данных (и только свою базу данных) для выполнения вещи это должно сделать. Импорт данных через phpmyadmin работал просто отлично.

Я могу получить доступ к бэкэнду CMS (который должен уже иметь дело с базой данных).

Если я пытаюсь получить доступ к веб-интерфейсу сейчас, я получаю следующую ошибку:

Fatal error: Uncaught exception Exception with message Query error: 
Lost connection to MySQL server during query (<query statement here, nothing special, just a select>) thrown in /var/www/system/libraries/Database.php on line 686

(Имейте в виду: я могу получить доступ к mysql с помощью phpmyadmin и через бэкэнд, работая как charme, это просто вызов внешнего интерфейса, вызывающий ошибки).

Если я спамлю F5 в своем браузере, я иногда могу даже убить mysql deamon.

Если я запускаю

# mysqld --log-warnings=2

, я получаю это:

...
120921  7:57:31 [Note] mysqld: ready for connections.
Version: '5.5.24-0ubuntu0.12.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
05:57:37 UTC - mysqld got signal 4 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346679 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f1485db3b20
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f1480041e60 thread_stack 0x30000
mysqld(my_print_stacktrace+0x29)[0x7f1483b96459]
mysqld(handle_fatal_signal+0x483)[0x7f1483a5c1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f1482797cb0]
/lib/x86_64-linux-gnu/libm.so.6(+0x42e11)[0x7f14821cae11]
mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyyb+0x1368)[0x7f1483b26cb8]
mysqld(+0x33116a)[0x7f148397916a]
mysqld(_ZN4JOIN8optimizeEv+0x558)[0x7f148397d3e8]
mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0xdd)[0x7f148397fd7d]
mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x17c)[0x7f1483985d2c]
mysqld(+0x2f4524)[0x7f148393c524]
mysqld(_Z21mysql_execute_commandP3THD+0x293e)[0x7f14839451de]
mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x10f)[0x7f1483948bef]
mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1365)[0x7f148394a025]
mysqld(_Z24do_handle_one_connectionP3THD+0x1bd)[0x7f14839ec7cd]
mysqld(handle_one_connection+0x50)[0x7f14839ec830]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f148278fe9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f1481eba4bd]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f1464004b60): is an invalid pointer
Connection ID (thread ID): 1
Status: NOT_KILLED

Из /var/log/syslog:

Sep 21 07:17:01 s16477249 CRON[23855]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Sep 21 07:18:51 s16477249 kernel: [231923.349159] type=1400 audit(1348204731.333:70): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=23946 comm="apparmor_parser"
Sep 21 07:18:53 s16477249 /etc/mysql/debian-start[23990]: Upgrading MySQL tables if necessary.
Sep 21 07:18:53 s16477249 /etc/mysql/debian-start[23993]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Sep 21 07:18:53 s16477249 /etc/mysql/debian-start[23993]: Looking for 'mysql' as: /usr/bin/mysql
Sep 21 07:18:53 s16477249 /etc/mysql/debian-start[23993]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Sep 21 07:18:53 s16477249 /etc/mysql/debian-start[23993]: This installation of MySQL is already upgraded to 5.5.24, use --force if you still need to run mysql_upgrade
Sep 21 07:18:53 s16477249 /etc/mysql/debian-start[24004]: Checking for insecure root accounts.
Sep 21 07:18:53 s16477249 /etc/mysql/debian-start[24009]: Triggering myisam-recover for all MyISAM tables

Я использую таблицы MyISAM во всем , ничего с InnoDB там нет. Запуск / остановка mysql осуществляется через

sudo service mysql start
sudo service mysql stop

После небольшого использования Google я немного поэкспериментировал с таймаутами, корректным путем к сокету в файле /etc/mysql/my.cnf, но ничего не помогло. Существуют некоторые старые (с 2008 года) ошибки Gentoo, в которых перекомпиляция только что решила проблему. Я уже переустановил MySQL через:

sudo apt-get remove mysql-server mysql-common
sudo apt-get autoremove
sudo apt-get install mysql-server

без каких-либо результатов.

Это первый раз, когда я сталкиваюсь с этой проблемой, и я не очень опытен с такого рода mysql «администрацией».

Итак, в основном, я хочу знать, может ли кто-нибудь из вас помочь мне, пожалуйста:)

Это ошибка в MySQL? Что-то сломано в репозиториях Ubuntu? Является ли это одной из тех загадочных проблем как «использовать tcp-соединение-вместо-сокета-вещи-потому-что-есть-проблемы-на-виртуализированных-машинах-с-сокетами»? Или я совершенно не в том направлении и просто что-то не так настроил? Помните, что phpmyadmin и доступ к бэкэнду (который использует базу данных тоже) просто в порядке. Может быть, что-то с Apache? Что я могу сделать?

Любая помощь приветствуется, поэтому спасибо заранее:)

Редактировать: Я попытался использовать протокол tcp вместо локального сокета, как описано здесь , К сожалению, это ничего не изменило.

Есть идеи у кого-нибудь из вас?