Проблема с MySQL

Аватар пользователя Arturus Arturus 14 августа в 2:17

Подскажите, в чем может быть проблема? При входе на сайт получаю сообщение
"PDOException: SQLSTATE[08004] [1040] Too many connections in lock_may_be_available() (line 167 of /srv/http/includes/lock.inc)."
В логах сервера есть ошибка PHP Warning: Uncaught PDOException: SQLSTATE[HY000]: General error: 1036 Table 'semaphore' is read only in /datebase/datebase.inc'

Комментарии

Аватар пользователя bsyomov bsyomov 14 августа в 18:50

Вторая ошибка, может быть из-за серьёзных проблем с mysql, если сломано что-то в структуре его данных, например, если что-то с хранилищем, или кончалось место. Или права не те на файлы.

Тут надо смотреть в лог mysql.

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

А после чего это началось?

Аватар пользователя OldWarrior OldWarrior 14 августа в 19:18

bsyomov wrote: Первая может быть следствием частичной неработоспособности mysql из-за второй ошибки, если есть какая-то нагрузка, которая может скушать все доступные соединения.

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

Аватар пользователя OldWarrior OldWarrior 15 августа в 9:21

Вы сами выше ответили: "если что-то с хранилищем, или кончалось место". Я бы ещё добавил: также при недостатке оперативной памяти.

А в общем случае: повреждённые или частично повреждённые таблицы (если метод хранения InnoDB). У меня был случай на одном из проектов, когда после DDOS сразу несколько таблиц сообщили о read-only. Тогда удалось вернуть таблицы к жизни народным средством innodb_force_recovery = ...

Аватар пользователя bsyomov bsyomov 15 августа в 11:20

Ну тут не нагрузка, а повреждение хранилища, всё равно. Вообще, довольно странно, что удалось этого добиться ddos.
При недостатке памяти, обычно оно не рушится всё же.

Аватар пользователя OldWarrior OldWarrior 15 августа в 12:07

PS. Вообще - речь же о возможных причинах. Сломанное хранилище в этом смысле - следствие. На типично настроенном хостинге таблицы/хранилища обычно сами по себе не ломаются. Тут нужно какое-то экстраординарное событие, обычно извне - типа резко возросшей нагрузки, чьих-то кривых рук и т.д.

Аватар пользователя ivnish ivnish 2 сентября в 14:00

Когда сайт ругается на эту таблицу, скорее всего просто не может достучаться до БД в целом. Проверьте соединение с БД

Аватар пользователя bsyomov bsyomov 2 сентября в 14:43

Не совсем. Здесь подключение есть, а таблицы нет. Когда нет подключения будет другое сообщение.
Может с префиксом что-то напутано или действительно нет таблицы.

Аватар пользователя bsyomov bsyomov 2 сентября в 14:48

Это свой сервер, или какой-то хостинг?

Если сервер, жив-ли накопитель на котором лежит база? Что в его smart? Что в dmesg, нет-ли сообщений об ошибках чтения/записи?
Также, вполне вероятно, что надо было заново вообще пересоздать структуру данных mysql, а не просто восстанавливаться из бекапа.

Если хостинг, вероятно, стоит писать в техподдержку. Хотя я бы при таких проблемах просто его бы вообще сменил.

Аватар пользователя Arturus Arturus 2 сентября в 15:16

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

Аватар пользователя bsyomov bsyomov 2 сентября в 18:29

Вам нужен кто-то, кто сможет нормально диагностировать проблему, имея доступ к серверу.
Методом вопрос-ответ это всё сделать будет очень сложно и долго.

К тому же, проблема не на стороне Drupal.