Мы уже дважды зависали в базе данных и пытались найти причину.

show processlist
Waiting for global read lock | INSERT INTO {myisam_table} ...

Здесь дисковое пространство было переполнено, поэтому мы подумали, что проблема закончилась после того, как мы дали ее еще немного, но на следующий день в полдень она снова зависла:

show processlist
Waiting for table level lock | UPDATE {myisam_table} ... 

Что может быть причиной?

Mysql Двигатель по умолчанию: InnoDB.

База данных имеет смесь таблиц с движками MyISAM и InnoDB.

Журнал размещен здесь:

http://arturito.net/2013/08/28/mysql-waiting-for-table-level-lock-errors/

НАЧАЛЬНЫЕ ЗАМЕЧАНИЯ

• Идентификатор процесса 42686 говорит, что готовится выполнить запрос SELECT
• Есть некоторые спальные связи
• Все остальные процессы не могут получить блокировку таблицы
• Я ожидал, что UPDATE, DELETE или INSERT сделают блокировку. Нет претензий на право владения рассматриваемой таблицей.
• Не могу увидеть полный запрос в Process ID 42686, но я подозреваю , что это вовлекает JOIN, GROUP BYилиORDER BY

РАБОЧАЯ ТЕОРИЯ

Если вам не хватило места на диске со списком процессов, который вы мне дали, то мы можем обвинить механизм хранения MyISAM. Почему?

В вашем конкретном случае это не одна из ваших таблиц. Если JOIN, GROUP BYили ORDER BYбыло выполняются и таблица температуры была записи на диск (на диске временных таблицы использовать механизм хранения MyISAM) для MySQL просто замерзает , когда из космоса. Откуда я это знаю?

Согласно справочному руководству по сертификации MySQL 5.0

Страница 408 409, раздел 29.2, пункт 11:

Если при добавлении строк в таблицу MyISAM не хватает места на диске, ошибки не возникает. Сервер приостанавливает операцию до тех пор, пока не освободится место, а затем завершает операцию.

Я обсуждал эту ситуацию раньше

• Apr 05, 2013: «Сайт отключен» MySQL-сервер не запускается и не останавливается
• Dec 17, 2012: Как решить MySQL «Таблица заполнена» ошибка 1114 с Amazon RDS?
• Apr 25, 2012: Очень большие файлы журналов
• Mar 15, 2012: Почему происходит сбой таблиц MySQL? Как мне это предотвратить?

Что-то говорит мне, что у вас есть одна из этих двух ситуаций

• дисковые временные таблицы для ваших SELECT и борьбы за место с вашими обычными данными
• Если временная таблица находится в /tmpкорневом разделе, ей не хватает места

SUGGESTIONS

Предложение №1: сопоставить tmpdir с другим диском

[mysqld]
tmpdir = /another/disk/besides/root/partition

Предложение № 2: Создать RAM-диск

Запустите этот код, чтобы установить RAM-диск, который будет доступен при перезагрузке Linux.

RAMDISK_SIZE=32g
service mysql stop
mkdir /var/tmpfs
echo "none   /var/tmpfs  tmpfs  defaults,size=${RAMDISK_SIZE} 1 2" >> /etc/fstab
mount -t tmpfs -o size=${RAMDISK_SIZE} none /var/tmpfs
cp -R /var/lib/mysql/* /var/tmpfs
mv /var/lib/mysql /var/lib/mysql_old
ln -s /var/tmpfs /var/lib/mysql
chown -R mysql:mysql /var/tmpfs
chown -R mysql:mysql /var/lib/mysql
service mysql start

Затем сопоставьте tmpdir с/var/tmpfs

ДАЙТЕ ЭТО ПОПРОБУЙТЕ !!!